A Pessimistic Approach to Software Design

[swatts]

I think pessimism is viewed differently depending on where in your world you live. In certain companies it's actually viewed as a terrible, career reducing attitude. In this article I'm going to describe how being pessimistic can be vital in design and how designing with a pessimistic attitude can make your life very much easier going forward. 

Example #1 You'll get a full set of requirements

You won't, ever.

If you get requirements that are 90% complete at the start of the project I'll guarantee 20% will be wrong. As I've talked about before, writing requirements is equivalently hard as writing software, especially if the language you use is suitably expressive. Armed with this information should temper your design decisions, try not to make change expensive. I have written plenty of articles on this subject. 

Example #2 There will be no bugs in your code

There will.

Your tests will be polluted by how you use the software and as the author you will use it "correctly". You'll avoid the pitfalls and traps, because you know they exist. To prove my point, just chuck your "fully debugged" code at some new users and watch it crumble to dust. You can't beat time with the machine and customer at the end of the project, cost accordingly. Track issues!

Example #3 Customers are the domain experts in their product

Often, not so much.

It's actually an unusual and pleasurable experience to deal with customers that know all about their products and can/will communicate this effectively. Don't expect it though, quite often you'll be disappointed. Prepare to be the domain expert.

Example #4 Replacing an existing system will be less risky than starting from scratch

As we learnt this year....it depends

The optimistic view is that we have a set of well defined tests ready to go. As we have a working system we can refer to it when things go awry.

Reality is that the system would have been put together years ago, by a domain expert who has now left the company/retired. Because it is an automatic system the domain expertise has declined too. We are now fault-finding 2 systems and the product being tested, because it's failing to spec. Dig below the surface and try and find the domain expertise, ideally someone who can do the manual tests that verify the automatic tests.

Example #5 Hardware drivers will be well written and easy to use

Or they might be crap and difficult to use!

I particularly enjoy the Serial Protocol wrapped in a DLL solution. Try to find equipment where the drivers are not a dead-end.

On an optimistic note, it'll turn out alright in the end..........................................maybe!

Steve