Taste is not debatable, which also applies to the taste in cars. But we won’t talk about cars today, we are going to talk about developing software applications. Recently, I started a new project and have to face new designs. Here I hope to see true beauty, and sometimes it works and sometimes it doesn’t. But what exactly is this beauty? Is that the simplicity of the Duck or the force of the Ferrari? And what characteristics are crucial? In this blog we discuss some considerations on the basis of three criteria. 

 

1. Functional operation

It seems so simple: the completed application must fulfil the requirements. So for the car the requirements could be: we want to go from place A to B with two people and cover 50 kilometres in one hour.

In this case, both cars are sufficient. So how do we make the choice? We can try to answer the following questions for a good trade-off:

  • What is our budget and when do we leave?
  • Do we often go on trips and and should the car start immediately?
  • How good is the path we take? Are there barriers?
  • How bad is it if we have problems with the car?
  • Are there parts where we have to drive faster or slower?

2. Available components and environment

Our choices depend on the materials and tools we have at our disposal. Again, this seems obvious, but sometimes it is unseen. Questions we should ask ourselves then:

  • What engines can we have at our disposal?
  • What tools can we use for assembling?
  • Do we perhaps have an old fixer-upper in the garage?
  • Where can we make our test rides?

3. Future maintenance

Personally I think this is a very important subject. Most of the costs of a car are used for the maintenance of the car. It highly depends on the complexity and the associated time needed to understand what is going on when problems arise. So ask yourself:

  • Are the technicians sufficiently trained to maintenance the car?
  • Do they have experience with similar techniques?
  • Can they solve problems without studying a thick tome?
  • Are parts easy to get or to imitate?  

 

Screen Shot 2016 09 14 at 13.02.19

Back to the daily practice

Maybe the comparison with cars for IT development seems a bit far away, but I think colleagues will recognize it:

The Ferrari model is like a clever piece of software: it handles large amounts of data in a very limited timeframe. All unnecessary logic is beaten. It is an important piece of work, that is why it is often used as an example and benchmark is cited. But when there is a bug, none is keen to pick up the job for the detection. And unfortunately that expensive developer who built the module just left…  

The Duck is an example for simple software that doesn’t contain many distinctive components and just does what it should do. If there is any problem with it, everyone wants to find the bug, because everyone is convinced that they'll find the mistake. The developer left the project a long time ago without any problems: the rules are so recognizable that everyone could have think of it. Nevertheless, the application is unique because of her features.

 

So, which car should we choose now?

I do not drive a Ferrari or a Duck. At home we are well discussed what we expect from a car, particularly with regard to the usage and the expected costs of maintenance and taxes. The Ferrari and Duck are both stereotype of beautiful cars, but we make concessions in different areas.

This strongly suggests that it is important not to face unexpected situations. Within IT, these properties are often grouped under the "non-functional requirements." If we make this sufficiently explicit than there is the possibility of ending up with a very good maintainable application, which can handle in terms of speed or vice versa.

But if all the requirements have been discussed and defined, there is no one who prohibits a developer to create a new "design icon". Maybe it will succeed sometime within my own projects!

  

About Marco

I am a Business Process Management consultant who enjoys the act where business meets IT. I find my challenges in translating IT to the business people, and business to the IT people. I enjoy using ever expanding BPM, decisioning and data management capabilities to continuously optimize business value. 

Marco Bussemaker Senior BPM Test BPMCompnay