Rereading “Implementing Lean Software Development”

After some time I reread Mary and Tom Poppendieck’s book and came to a paragraph that had previously not caught my attention (or I forgot that it had). In my defence it was in a passage about Google (which is not of particular interest to me) underneath a prominent insert, but nonetheless, it struck a nerve with me now, since there are lots of discussion about the Death of Agile for quite a while now:

“This is also the time [feasibility phase] for systems design, a critically important discipline that many companies seem to do without. […] It should neither be done by an amateur nor by arms-length experts. Rather it should be done by seasoned designers who know the systems design will evolve as the product emerges and who know how to make sure that evolution is taken into account so it can proceed smoothly.” (p.47)

So, there you go, one of the major pitfalls. From my own sad experience I can say that system design is the barren wasteland in most companies building software products. They do Scrum, Waterfall, Unified Process, Kanban, XP, Lean, you name it, but on the systems design level decision are still often made with arguments like:

  • [Big company] is using it and they have millions of users, so if it’s good enough for them…
  • Everybody knows that X is the best for Y.
  • You know X is really an expert in [programming language, tool, technique] so we take it.
  • Our old software was running for a long time with X, we should stick with it.
  • X is really around for a long time. At least we would know all the problems and could google them.

I’m sure everybody knows meetings where arguments like this come up (and many more equally sad ones). Normally not from the development team, but the management. But why?
Building a new product is a risky business, you can fail. This is scary. And scared people try to get safety wherever possible, thus forcing a technical solution onto the developers because they can’t give you a guarantee for the projects success and let’s be honest when did the technical gibberish of developers ever beat the argument that f***book or whoever is using it? So the development is left with screws and a hammer and tries bravely to use the impact of the hammer to make the screw rotate, because some other big company is using nails and hammers.

But what to do about this screwed up situation (pun fully intended)?

If you don’t have a seasoned designer on your team it is easy: Hire one, get a consultant, research, discuss
If you have one: Let her/him do his job and don’t try to get guarantees, there are none.

So my feeble take on systems design:

  1. Avoid big enterprise frameworks (unless you are big, as in massive).
  2. Microframeworks are more likely to be able to allow changes due to their pluggable nature.
  3. Define the platform you want to run the software on early and keep deployment in mind.
  4. Plan without css/js frameworks and add them if they provide a significant benefit.
  5. Enforce coding styles and guidelines early on. Otherwise changes and debugging will be a death by a thousand papercuts.
  6. Encourage learning and teamwork to improve code quality and knowledge of the system.
  7. Try your best to keep employees to avoid knowledge drain.
  8. Estimates are not deadlines! Cutting corners to keep a deadline that was an estimate will cost you dearly later.
  9. Automate early!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s