Friday 2 November 2007

Best Practice in Software Development

IBM has a nice page on Best Practice in software development. It's amazing what such a page doesn't list. For instance, UML is the only method listed for design, even though there are alternatives and UML has known caveats.

It also mentions "Keep it simple" and "Information hiding" as some of the most important principles. I totally disagree. I consider "Make complex things easy to use" as the most important principle. It is ok for things to be complex, and it is ok not to hide information, but it is unforgivable to create something that is too complicated for others to use. A software developer should spend most of his/her time on making complex things easier to use for others.

Best Practice methods require preconditions and they are absent, too. There are different kinds of software development projects, different kinds of project teams, and they require different methods. There's a huge difference between developing control software for a moon rocket, developing search algorithms or creating user interfaces for database applications. Unfortunately, it seems that most attempts to define Best Practice forget about preconditions.


Anonymous said...

The most common mistake in project metrics is choosing the wrong measure, or measuring the desirability of an OUTput rather than measuring correctness of INputs.

By keeping things simple and by hiding information, helps to ensure that things that could easily become complicated remain easy to use.

Starting off with a "make complex things easy to use" rule, it would be all to easy to end up in a situation where something spirals INTO complexity because it wasn't initially considered complex enough to warrant being made easy to use.

By keeping the two fundamental rules paramount, rather than shaping a rule in terms of the desired outcome, then your OBJECTIVE is made easier to attain.


Lars D said...

Good points. Hiding information is one of the techniques that can be used to make things simple to use. Keeping things simple is another technique, which both makes things simple to use, and can improve the programmer's productivity.

However, in a team, a single programmer's productivity is rarely decisive for the team's productivity, but if the output of a programmer is difficult to use, it can severely impact team productivity, and you will need to fix it.

Different programmers have different minds, and some automatically make things simple, and some don't.

I require my programmers to make things simple to use. As long as the interface section of a unit (one file in Delphi) is very easy to use, and the unit is without bugs, it doesn't matter a lot if the implementation is complex.

For instance, we have an XML parser which is easier to use than most other XML parsers out there, but the implementation is complicated, because it has been heavily optimized for speed. However, the complexity of this unit does not affect team productivity since the team members only look at how to use the unit.

Anonymous said...

'It also mentions "Keep it simple" and "Information hiding" as some of the most important principles. I totally disagree. I consider "Make complex things easy to use" as the most important principle.'

Hmm, I would say, "Information hiding," is one answer to the question, "How?" which might be asked after hearing the directive, "Make complex things easy to use."

The reverse is certainly not the case, suggesting that, "Information hiding," is somehow easier to do (being more specific) than, ""Make complex things easy to use."

And you may be interested to hear that encapsulation theory can even prove how information hiding reduces complexity for some systems, see here:

Or, if that's too much, at least take a peek at the graph of complexity versus number of encapsulated regions here:

Ed Kirwan

Lars D said...

Information hiding and reduction of information is not always good. Human language is a good example: It contains a lot of redundancy in order to be easier to understand, and it contains many constructs, that are only present in order to make it easier to pronounce and use.

The same applies to programming. If you hide something that may make it much easier to understand, you actually reduce the productivity of your team. Redundancy, extra steps and extra complexity can actually make things easier to understand and use. For instance, if you can make an api behave exactly like something the user already understands by adding complexity, this may be better than a much simpler solution, that the user doesn't understand. I'm not trying to advocate complexity, I'm just providing some examples of why information hiding itself isn't a solution.