Design: Documentation or Code
For a while I have not been visiting Martin Fowler's Bliki. The reason is a bit silly. My feeds fall into two pseudo-categories: those I [used to] read from work (about 75) , and those I read at home (about 60). For 2 months I have been neglecting my "work feeds". At my new job the project I work on has pretty tough deadlines and I try to keep myself focused. So my only source of refreshing reading at work is Mike Gundelroy (that is an average of 3 links to follow each day).
But two weeks ago I saw something related to RSS Bandit and I downloaded it to give it a try. I have been using SharpReader for ages and I have to say that RSS Bandit was a breath of fresh air. It has more features, more options and is better polished. So, while giving RSS Bandit a try, I imported my "work feeds" OPML and was seduced to restore my reading practice. At my previous job this activity consumed an average of, I guess, 45 minutes a day (that is about 10% of my worktime). But strangely, I had not come back to this habit, this is probably the third time in 2 weeks I even start the aggregator (and two of those three days were Saturdays:) )...
So what was I talking about? A yeah, about CodeAsDocumentation post, which has a reference to the "What is Design?" article. Strangly, I had not heard about this article before/ And there is a fresh follow-up What Is Software Design: 13 Years Later . So yesterday I read those and a few things are still in my head.
- Whatever documentation is produced that is to describe design of a system, the real and final design is the code itself.
- There is an important distinction between design as a process and design as a product.
- Code, test and debug your design in a spiral manner, since putting too much effort only in unproven top level design doesn't guarantee a success.