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.
3 comments:
My problem with waterfall (well, one of them), is that in the process you described, you are doing two things:
1) writing UML diagrams
2) writing the code
3 to n) updating code and UML diagrams when changes occur
In agile you do this:
1) write the code
2 to n) update code when changes occur
That's half the work!
Correct me if I'm wrong (I'm not the waterfall expert), but UML diagrams are different from functional specs/tech specs. You always have to have tech specs or you don't know what you're writing.
But what's the point of creating design documentation? It's out of date pretty much as soon as you write it, and you will spend lots of time keeping it up to date. But what for? You've written the code, you've written, your tests and it works. Why do you even need a UML diagram at that point?
It's hard enough to keep tech specs up to date. I can't imagine having to keep UML diagrams up to date too.
First thing I think I should clarify is that I mentioned UML is merely a means to an end. UML and any other artifact is only as valuable as how well it communicates your design to the customer - and allows you to get feedback. If a conversation, cocktail napkin, Visio sketch, or wireframe does the job better - use that. The goal is to fail fast in whatever way you communicate. The question is which communication method is easiest.
Keeping the communication tool up to date after it's served it's useful purpose of communication is left up to another decision. Is there a compelling reason to keep that document alive? If there is then keep it in parallel with code, otherwise scrap it.
The whole point of communicating the design in a picture or other form is to theoretically make your code better when you write it the first time (at a fraction of the cost than it would cost to write code). I'll generally argue that a communication tool (UML, etc.) is easier to change than code. Plus, when you think of documentation you think of sign-offs, bureaucracy, pointy-haired bosses, etc. I say leave those time-sinks out of it.
Of course, sometimes there is just no substitution for working software. If you think your customer can only provide feedback after seeing working software then don't put the effort into other methods.
Most customers don't give a damn about UML class diagrams or the architecture of your application. They care about usability and behavior. While some of these aspects can be expressed in other types of UML diagrams, the best communication is through demonstrating or delivering real software (even when portions are mocked).
The people who care most about design and architecture are the maintenance developers who come after you (or are a "future" you).
Post a Comment