
I've been developing software for quite a few years. One of the issues that seems to come up again and again in my work is this concept of design and implementation. I recall it being a significant part of my education at the University of Waterloo's Computer Engineering program as well. The message was always the same. Never write code first. First you must design software by writing a design document, flow charts, pseudo-code, timing charts... then it's merely a trivial matter of implementing it. Make note of the attitude here given towards implementing. The real work is in the design, and it's just a trivial matter of implementing it. It sounds so simple doesn't it? Now, how often does this work out in real life?
Member since:
2005-08-12
It's a good article, but he independently discovered an already well-established philosophy: don't document just for the sake of documentation.
on the same page.
It sounds like the author works at a company which doesn't believe in selectively documenting a system, but it's well established in ALL the software process camps that the trick to success across the SDLC is to "realize what decisions you can defer and what you must take now" - that is, only specify what needs to be specified beforehand, and leave the more trivial decisions for when you're in the IDE.
The software development body of knowledge is massive. There are a ton of strategies available for a software team to use: use cases, invariants, sequence diagrams (a personal favorite) - in fact, there are probably formal ways to describe every single aspect of a piece of software. But that doesn't mean you have to! Use common sense and remember why you're documenting: to get your development team (and maybe stakeholders
That said, thank you Yamin for writing this article, because you started a good, substantive conversation about a topic that's way more interesting than anything that's been published on this site in a long time.
Edited 2009-09-10 02:50 UTC