I recently found two posts online discussing the topic of doing design up front. This is something that Agilists tend to run away from and if they find anyone doing it, they accuse them of BDUF (Big Design Up Front). Where I am working right now, we do it at the beginning of every iteration. Each developer gets their assignment and the first thing they do is UML(Unified Modeling Language) diagrams and written test plans. For us, since we are dealing with a lot of co-op students, it works quite well as it allows us to catch a lot of errors early. It also forces the developers to think through what it is they are building.
“The first article is on the Dancing Mango website”:http://www.dancingmango.com/blog/2006/10/24/upfront-is-good/ and basically states that the “Agile Manifesto”:http://www.agilemanifesto.org/ does not exclude up front design or analysis. In fact, it goes so far as to say that it is a good thing.
bq. The “Agile Manifesto”:http://www.agilemanifesto.org/ states “Working software over comprehensive documentation”. Note the use of the word “comprehensive”. It doesn’t state “working software over documentation”. It also states (and this is all too often forgotten) “That is, while there is value in the items on the right, we value the items on the left more”. It is essentially pragmatic, do just enough that is necessary to allow you to be successful. This is most important in the field of analysis.
The main thrust of the article is to do just enough documentation so that the business people and the developers are all on the same page.
bq. Bottom line: Do up front analysis and be proud of it. Make it just-enough in a format that is appropriate (so why is it suddenly OK that it is on the Wiki rather than in a Word document on the corporate LAN?) Get it out there!! Stick it on the walls, let everyone see the business objectives, who the users are (personas), the competition, the wireframes, the product mission statement.
However, the article does not mention UML(Unified Modeling Language) or design and mainly concentrates on the business end of analysis. For a discussion on design, I present the second website–Javalobby.org–on which there is a “discussion thread on UML and its merits.”:http://www.javalobby.org/java/forums/t83806.html The original post asks the question: How much designing should be done before coding?
I am not going to summarize the entire discussion, but I do think it is well worth reading. In my opinion, it highlights the two sides of the issue nicely. On one side are the architect, enterprisey people who rely on UML(Unified Modeling Language) and design before ever coding to code. They demand that every new hire be fluent in UML(Unified Modeling Language). On the other side are the newer Agile people who would rather go straight to code and test-driven development and would rather hire people who can code and UML(Unified Modeling Language) knowledge is a distant second, third, or forth thought.
I tend to side with the Agile camp, but I can also see the advantage of doing UML(Unified Modeling Language) designs before starting code. I think there is value in thinking through a design, modeling it, and maybe even attempting to apply some design patterns to the model before you move into code. On the other hand, as a programmer, I definitely see the attraction to moving straight to code. I have created far too many design documents that, after one good day of coding, were out of date and were never updated.
In the end, I think my opinion is to do just enough design and modeling to allow you to move intelligently to code. And skip the upfront Word documents for the test plans, those are just a waste of time. Test-driven development will take care of those.
