Software Engineering in Large Organizations: Design

(Another in a series.)

When you work at a big software company, the design choices that you make today will shape your destiny for years to come. Much more so than at a smaller, more agile unit that may throw out code or rewrite it with abandon. The reason is simple: the tradeoffs are different when a bunch of people are trying to make improvements to the same thing at the same time.

There is always pressure to put the squeeze on design time. I don’t know how many times (on certain teams) I was asked to complete design in one week out of an eight week sprint. Even then, I sometimes had to spend half of that time cleaning up messes from the previous sprint. So much for measure twice, cut once! It’s true that everyone says that they need more time for each phase of a project, whether it’s requirements, design, implementation, or testing. But I really mean what I say – too little time is spent on design. If given the choice I would gladly trade implementation or testing time for design time, because when I design I still control my own destiny – even over requirements. Once coding begins, the team is carried along by the current and making changes is painful. It’s ironic that all of these things are true, yet the pressure to squeeze design time is entirely justified. There is a huge tendency, even among senior developers, to tinker, re-tinker, and re-re-tinker with designs. Making them bigger, smaller, more intricate, more abstract, and so on.

You can strike a balance by ensuring that:

• Dedicated time is allocated for design (and only design). Reducing this time means reducing project scope.
• There is a clearly defined deliverable (such as a design document and/or a presentation).
• Design starts on an individual or feature team basis and includes more people only as more confidence is developed.
• Design reviews (informal or formal) always happen before the designer is comfortable with what they have. This ensures that feedback comes after there is sufficient “meat” in the design, but before the designer is totally fallen in love with their ideas.

It’s common to underdesign important things and overdesign unimportant things. The tips above help to avoid both.

It’s also appropriate to change your design approach based on the type of component you’re dealing with. I wouldn’t design an airplane the same way I would design a toothbrush. UI frameworks are rewritten over and over. Calculation engines are not. Business rules are often changed or extended. Databases are often joined or merged but rarely discarded. Glue code is glue code.

At a big company, platform considerations are important but rarely under your control. Someone else has already made those decisions, and you are likely stuck. So you’ll have to learn to design under those constraints, but think of it as a challenge and not a burden (even though it is both).

NCAA Tournament Wrapup

Hail to the champions, the University of Kentucky. I only got one of the four Final Four picks correct, but luckily that turned out to be the champion. My SAS-generated picks turned out to be in the 71st percentile of all those who participated in the Yahoo NCAA challenge. Not bad.

Careful readers may have noticed that my code had a somewhat serious bug in it: the exponent in the “pythagorean” formula that I relied upon was supposed to be 11.5, but I had 1.5 in my code. Oh well!