Alternating Element Highlighting With jQuery

Reading tabular data is usually made a little easier by distinguishing alternating rows by a slightly different color.  Normally, to accomplish this I would just assign a different CSS style using a server control such as a GridView or Repeater.  While working today, I found a challenge in applying the alternating row effect because I was outputting a static HTML table with some dynamic rows thrown in the middle using a Repeater.  So depending on how many dynamic rows were rendered, sometimes I would get two rows by each other with the same color.

So anyway, the solution was to implement the alternating row coloring on the client using jQuery.  Here is the very simple code:

You can even substitute the <tr> tag to any html container (div/span/etc.). 

jQuery rocks!!

The Balance in Design

Everything in software is about balance.  Today I was thinking about the balance of design.  There are about an equal number of equally passionate folks on either side of the debate; some say design everything up front, and some say design as you code.  I say, consider both and find the balance.

Designing everything up front is usually associated with a Waterfall model, where by definition the design is done first.  Design-as-you-go is favored by Agilists who assume that all design should emerge as code is written.  Agile design is communicated in the form of code and working software, Waterfall design is communicated through a series of diagrams or UML.  Regardless of approach, the common denominator is that you are communicating design so your customer can provide feedback. 

The Waterfall approach forces the design so that you can make decisions before you code - which makes a lot of sense; you can't write bugs if you don't write code.  When this design is communicated effectively and the customer agrees that it is correct, you've got a greater chance of coding it right the first time.

The Agile approach is to design as you go.  As more requirements emerge, the developer doing the construction can make the best design decision possible because he/she knows the very most about the domain that they can.  After all, you can't know more about the problem and existing application design than you do the very minute you write the code.  When that code is written, the design can be communicated back to the user in the form of working software, and the customer can provide feedback. 

So here is my point.  Writing code is costly in time and resources, and it's a lot of effort just to find out whether or not you've solved your customer's problem.  If you can communicate your design by other communication mechanisms (UML or diagram) to get feedback, why wouldn't you consider that?  In some cases you'll be able to get feedback without writing code; in some cases you won't.  There's a decision there that will probably be based on how well you know your customer and how complex the design is. 

The point is to make sure you're always advocating for the customer, trying to get the most bang for their buck.  Be cognizant of a variety of approaches to solving the problem, and use critical thinking to judge which will be most successful.

Communication Is Hard

Communication is the process of conveying information from a sender to a receiver with the use of a medium in which the communicated information is understood the same way by both sender and receiver. (Wikipedia)

I've been reading Domain Driven Design-Quickly recently and reviewing it with some friends, and I've done a lot of reflecting on what value I think the book holds.  What really struck a cord with me was chapter 2, "The Ubiquitous Language". 

In summary, chapter 2 asserts the importance of developing a core language that is shared and understood between the customer and software developers.  In the context of the book, the authors point out the challenges of communicating requirements and success criteria for software development, but I'm taking this idea further and investigating other areas I can improve in my communication. 

For geeks like me, it's easy to talk for hours on methodologies, war stories, the cool latest tech, and so on.  I think it's fair to say that most of the time when we are talking, we assume that our audience is understanding what we're saying, but it's not always the case.  Think about all of the terms we throw out on a daily basis that can carry different meanings depending on context and your audience's experiences.  Here are a few of the usuals that are suspect for ambiguity:

"Service"
"Security"
"Model"
"Design"
"Framework"
"Business Object"
"Layer"
"Tier"
"SOA"
"Repository"
"Factory"

These words are all extremely useful, and convey very important software concepts.  But take a minute to think about how these words could take on different meanings when put into different contexts.  Not only that, but your audience may be thinking something completely different based on their training or experience.  In casual conversation, this carries little to no significance, but if you're explaining how you want a system to be constructed then you're going to be in for some frustration. 

Here are some of the communication touch points I make as a developer, and success indicators.

* The code I write.  Does it communicate clearly my intention and purpose as it relates to my client's business?  Are my classes well defined and have a single clear purpose?

* Interaction with my client.  Does my client understand the solution that I am delivering to him/her?  Am I able to convey my design decisions and where I am spending my time so that they feel as though I am providing as much value as I possibly can?

* Communication with team members.  Am I actively listening and making sure that we are really speaking in the same language?

If I'm not taking an active role in making sure that I'm communicating in a language that both parties understand, then I'm probably going to be misunderstood.  As a developer, I need to put more emphasis on communication.  It's one of the most challenging aspects of my job, and if done poorly can mean failure.