Geeks With Blogs
Dev.Hell Harrowing the tech business like it's 1999


DESIGN.BLUES
As regular readers have no doubt noticed, my overriding interest is design. While it's true that many success stories in the volatile world of IT have been due to luck or good timing, that's not a sustainable model on which to base a line of products or a business. Design discipline, I contend, is the primary difference between continuing success or ultimate failure in the software industry.

Most places I've worked design has been a problem of one kind or another. Usually, in small companies, there isn't any design of if there is, it's been abandoned. Even at the bigger companies this can be a problem: I worked for a software giant for a while and the site I worked at was utterly unproductive because my management was too frightened to authorize any kind of design... so they kept us occupied with busywork until head office shut us down completely. Then again, I worked at a tiny company where the design was held in such high regard that it prevented us from ever shipping any product: the architect was so intent on achieving the perfect design that he changed it on a monthly basis.

Right now, design is the main part of my job. I've designed software before, but usually it's been covertly, in the face of management who though design was 'too expensive' or that the direction they themselves provided (in one case, an Excel spreadsheet)  was more than sufficient. My first big project in this capacity kicks into gear next week and I thought this would be a good opportunity to assess my position on the subject.

Resistance is Futile
At school, we're all taught that design and documentation is of key importance, that planning a project properly is vital to its success. Why, then, are we so loathe to engage in the practice?

Well, firstly, because authoring a design means taking personal responsibility. If the design fails than it's easy to point a finger at the designer--he designed it, it's his fault. This approach is, frankly, not good enough. We are engineers, designing is what engineers do. Any project is much more likely to succeed, in the long run, if it has a design than if it's assembled ad hoc by the a dozen different members, none of them working to a certain direction. Yes, sometimes the design fails... but it's much easier to fix it if there was a design to start with. If the project is organized it can be refactored; if it's not it must be rewritten.

The second problem is that, well, design isn't coding--it involves writing words and drawing UML pictures. Developers code, right? Writers write, artists draw pictures, coders code. If we're not coding we're not working, right?

Wrong.

Writers and artists design their works just as software engineers do. Books, screenplays and essays have structure and shape; and so do paintings, photographs and comicbooks.

Design OD
Of course, it's entirely possible to take it all too far. Projects can overdose on design procedure.

I have a friend who is contracting to a giant IT business on a giant project, and his life consists mainly of attending seminars and workshops and coaching an army of project managers, while his own work gets further and further behind. Instead of doing his job--designing and building a system--he is being forced to appease a management hierarchy who are in turn trying to cover their own arses by enforcing a ridiculously complex procedure at the expense of any type of productivity whatsoever.

Designwork is just as productive as coding.  Arse-covering is not.

Down and Dirty Documentation
I work at a much smaller company--somewhere between 50 and 100 employees. In my capacity as design-monkey, I have produced a slew of documents and UML diagrams showing how I want the system to work... but not anything close to what my friend at the big boys is dealing with. I write short, highly targeted documents, addressing a specific problem or audience (high level design & integration is a specific problem, so is the behaviour of a complex algorithm). I tailor the format of the documents to the audience and the goal of the document.

People say that picture is worth a thousand words, but you simply cannot document a software system only with pictures. Studies show that a combining written words with a sequence of static pictures is the most effective way to communicate--comicbooks are a great way to teach skills or procedures.  You can forge a synergy  between the images and the works that is much easier to absorb than a slab of text or a hundred class diagrams. As a comicbook guy as well as a software engineer, this is something I've taken to heart.

I try to keep my design documents tight and to the point. I don't waffle on implementation detail; I don't show every single object or class or sequence, I just enough so that the team knows how the system needs to fit together without having every single detail dictated to them. They're smart guys, not children, they don't need to be spoonfed. Besides which, I know if I write too much the team just won't read it, even if I put GAME OF THRONES on the spine. There is a point where design ends and code begins, and I believe that finding it is the key to a presenting a successful design.

Once I'm happy with the design, I start to prototype it in code. Sometimes you can get a better insight into how things work from the inside and, as the architect of the system, I feel that it's my responsibility to assess the design from all sides. I need be able to prove that my pie-in-the-sky comicbook stories work as actual code if I expect the team to buy into it. I work remotely (29 hours is a pretty long commute to the office) but I will be actively coding with the team as the project proceeds--an architect in an ivory tower is no use to anyone.

OK GO
Once the system is designed it is up to the team to ensure that they stick to the design as best they can on the way to a release. It's never going to be a perfect match--there will be errors in the design and in the code-- but the closer we stick to the design the easier it is to control the schedule and to maintain the code after release. Unless the design is severely flawed there should be no stopping to reassess in the middle of the project.

The docs are pretty much done, the prototype works; next week I will present everything to the team and the build-out will begin. Let's go.

-- JF




Posted on Monday, May 12, 2008 12:59 PM | Back to top


Comments on this post: Design.Blues

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Jason Franks | Powered by: GeeksWithBlogs.net