Sounds like newspeak dunnit? Well, there is alot of uncertatinty when it comes to documentation and building software. Should you ask a team, mostly everyone would agree that documentation is good. If everyone thinks it is good, then why isn’t it happening? People know what they are supposed to answer, but they don’t know why. In fact, many secretly believe that documentation is a time-waster.
Documentation is useless because:
- Software is in a constant state of flux; documenting the changes is too hard
- No one reads documentation–program code is the real truth
My team doesn’t use documentation because:
- The software is too old–no one knows how things work anyway
- No one wants to pay for documentation
- We don’t have the time to document everything we do
If people really knew why specifications are good, they would be doing it all the time. My belief is that specifications are easily worth the time invested.
The use case
Here is something very much simplified, could be taken from an online system where customers purchase tickets to soccer games.
Examining this more closely, some questions turn up:
What if the game has already been played? Should the customer be able to buy tickets for past games?
What if the credit card data is rejected? Should we return the customer to the list of games?
What if the ticket server isn't available at the time of purchase? Should we undo our transaction from the customer credit card?
Unless we assume that the developer will find these items, and fill in the blanks, patching things up as he goes, the specification needs to be more detailed. I didn’t say better–it is fine for its abstraction level. But it needs more detail before it turns into working software.
If questions like these fall all the way through to the software coding level unattended, the application will turn out no better than the prescience of its developers.
Dealing with Lucky Luke
Again, why? Do developers really need specs? Can’t they just do it right? Well, obviously “right” is a matter of opinion. That is why we try to specify things, and alot of people, like Lucky Luke, they don’t like it.
The Cowboy coder
The genius Cowboy dislikes specifications because they hamper his freedom to do his thing–which is coming up with new genius solutions! Publicly he follows the company line. Privately he knows best and does as he pleases. The Cowboy coder is often covertly supported by the Pragmatist.
The pragmatist is a “genius” on the customer side who “gets things done”. Publicly dislikes specification and any kind of administration. Uses the “Yes yes, you keep on typing those docs. Just don’t bother us doers.” Privately fears specification because he understands it reduces his power and makes him accountable.
The Paper Shuffler
The Paper Shuffler believes that documentation exists in its own right. Documenting is simply something people in offices do, preferably with as much irrelevancy as possible. The Shuffler is often a failed doer (and humorously used as a straw man by The Pragmatist). Will slowly suffocate any good project with impossible hoops and hurdles if sufficiently empowered by higher-ups.
The three actually work quite well together; the Paper Shuffler keeps an outside apparency of order while the Pragmatist and the Cowboy coder “get things done”. It becomes a very private project that is difficult to change or understand.
This is the team that secretly uses a slackware linux desktop running apache and some obscure java beta framework as their production server, while at the same time renting an empty high-powered MS 2008 Server as the official server. They would, of course, be using that one if the server IT guys were competent enough to run it properly (and if C# was a real language).
With these teams, project documentation is impeccable while actual product documentation is sorely missing.
Specification and Agile
As a collection of ideas, agile (or Iterative) is awesome, because it openly distinguishes from waterfall which really was a horrible way of developing software. That doesn’t mean iterative development is unnecessary loose and haphazard; in fact one of its most popular methodologies, Scrum, is really quite formal.
The main thing about agile is its incremental and iterative nature. That is why I argue that agile is an enabler of strong documentation, because the method to write good specs is iterative as well.
Different life-cycles of specification (note, waterfall is not iterative development, only iterative maintenance).
In the figure above, I’ve tried to highlight the differences. The mixed method would be a team that sees the problems with waterfall, but doesn’t understand why specification is important in maintenance as well.
Iterative documentation process
- Specification is not mature until evaluated by implementation
- Specification changes with new requirements
- Specification lives alongside application during application life-cycle
Waterfall documentation process
- Specification is dead out of the water
- New requirements don’t change original specification
- Application is born out of specification, then discards it like a shell
Specification and implementation
Specification will very seldom be implementation quality from the get go. That is the faulty assumption waterfall makes. It is simply too difficult for the human mind to comprehend all detail before implementation is attempted. What you initially want to aim for is rough specification, with the intent to detail it later.
That is why specification refinement is an iterative process, and that will usually begin in the development phase. As code is written, the specification is continuously refined, continuously questioned, continuously improved upon.
Imagine a chemist piecing together a new theory late night at home, then going down to the lab the next day to see if it works.
“Huh uh, it blew up! Back to the drawing board!“, true enough for chemists and it should be true for building software as well.
Details? I’m a visionary!
Could you build a forest without knowing about leaves?
Description takes something to a higher detail level. It is a creative work where you add information that wasn’t there to begin with.
“If you have to squint to see them, you too can be a visionary!” — Yours truly
This is true all the way down to the software specification. As the programmer writes code, he is adding information. This information should not be guesswork. Don’t let it be guesswork. Specification in the form of guidelines and frameworks (which might be application or enterprise-wide) can help cut down on detail, but only if the team is aware of them. In fact, the team must not only be able to use them properly, but also know how to communicate their consequences.
When the team starts reading and writing specifications real knowledge sharing begins to happen. What used to be hidden is now out in the open and people will start imitating good practices. If you have a really good programmer, let the rest of the team learn from him by observing the way he writes specification and performs problem solving.
I first learned about the relationship between specifications and proper code from a very good senior developer. I was very much opposed to the idea of implementing changes in specification prior to joining that project, but reading his specifications was simply an awesome learning experience.
Specifications and testing
To test something, you need to know what to test. The detail of your testing, is directly related to the detail of your specification. If your spec is unclear, expect your test results to be unclear as well.“Well, this thing is supposed to send a mail if I do this and this. It seems it doesn’t anymore, did we change this?“ “This thing used to disable if this and that happened, but it is still enabled. Anyone know if it should be enabled in this new version?” “This thing now updates these things, but that doesn’t seem to work well with this other thing. Is it supposed to be working this way?”
See where this is going? We accept this because so many great minds tried, and failed before. We accept this because we know no alternative. It is of course unacceptable. The 1600’s had many great minds too, but not until the late 1800’s when methods of construction were finally formalized into a science, when design and construction was finally separated, did we manage to build skyscrapers. Exit the master builder stage left.
People still do that? As a developer, going through a folder of class prints before you dive into the code is very funny. Funny as in useless. If your code isn’t readable, chances are it sucks and should rewritten in an understandable way. You’re gonna be refactoring anything if you have to enter Visio to edit the class diagram? Crazy stuff.
Weak vs. Strong
- Implementation is guesswork
- No place for customer and developer to meet
- System knowledge is continuously forgotten, or lost when developer leaves project
- Understanding bugs is done by reverse engineering code
- Strong developer is decision maker. Team dutifully nods as oracle speaks.
- Implementation is translation of spec into code
- Customer and developer communicate through specification
- System knowledge is persistent and available to everyone
- Understanding bugs is done by reviewing specification
- Decisions are informed and often by team consensus.
How much is enough?
“How many angels can dance on the head of a pin?”
The answer to “How much?” is obviously, “Enough”.
The slightly longer answer is, “As much as you can stomach”.
The philosophical answer might be something along the lines of, “Document the information most subject to change”. Statics are usually well known and not interesting to document. If you would document a process, the biggest “obvious” steps change very seldom while the smaller higher detail steps get rearranged all the time.
Unfortunately, most documentation takes the opposite approach–we tend to document generalities; the big obvious boxes, while deftly leaving out the hidden details that describe how things work.
What we produce is absolutely correct yet perfectly useless.
Moving from generalities to detail implies accountability. It is arduous and time consuming but it needs to be done.
If you’ve read this far, and still disagree, let me tell you that alot of what I’ve written about above might eventually turn obsolete. Future software designers will snicker at the thought of documenting and programming (they will call it configuring) in parallel.
Looking ahead, more and more man-hours are being moved from the actual programming to figuring out what to program. This is because modern languages are making programming easier; plumbing is turning into mere configuration, data structures are plentiful and easy to use. What used to take a week to get working now takes a day.
Alongside these bigger building blocks will be an increase in visual tools. Programming by typing in code will decrease and visual designing (which is really closer to configuration) will increase.
As architects and developers (now software designers), generate interacting blocks of software out of visual models, these models instantly become approachable to team members outside the implementation group.
Models will decrease the gap between customer and developer, and remove the need for detailed specification.
That, finally, is self documenting software. What you see is kinda what you get.
Sure, implementation decisions remain, but these designing tools will be the new meeting ground for discussion to take place, for both developer and customer.
Until we get there, I suggest you do it by hand.