Saturday, July 29, 2006

What is a limit?

According to common sense it is simple to state that one thing is better than something else, at least as long as there is some aspect of the thing that can be measured. Stating that one approach to software engineering is better than an other does however not belong to the category of things that can be analysed in a simple way and does not seem to lend itself to any common sense approach. The problem is that there is not only one aspect to measure from which you can draw conclusions, but lots and lots of different aspects playing together, either making an approach good or bad. There are also lots and lots of "parameters" that can be changed and changing one thing will influence the others, even in unpredictable ways. Further more, changing one parameter any way possible may improve efficiency.

Theoretically there must exist a very best way to achieve something, but we don't know how good it is or where in the “parameter space” it is at. With any selected approach you can do better or worse, and finding the best way to archive a goal can be done by trial and error.

For example, by obtaining the latest development tools and making tool usage mandatory to a team of developers used to notepad / vi, delivery is delayed and amount of shipped bugs increase. The task for the team has become learning in stead of creating software. After the price is paid, and the team have done the learning and got used to the new tools the situation is totally different. Mundane tasks are automated by the tools, and tool specific quality assurance measures reduce the number of bugs. In this example you could say that by using notepad /vi the efficiency was trapped in a local maximum value. Getting out of this local maximum could have been difficult, but once done the efficiency increased. There are presumably many other things that could have been done, costing more or less, but before trying them out you can not really know if they would have worked better than the selected approach. There is neither any guarantee that the same approach will work on the next project.

Comparing to when scientists calculate the 3-D conformation of macro molecules like proteins and smaller molecules that bind to proteins, there is a simulation named Monte Carlo method being used, where you by repeatedly and randomly altering energy levels can get a good estimate of what the overall lowest energy conformation of the macro molecule system is. Repeated optimisation cycles and random alteration to the parameters will not guarantee that all possible conformations are evaluated but it does a pretty good job estimating the best conformation.

I don't know of any fully successful approach that would lend itself to study software engineering where you could experimentally or computational control the environment. We only do things once under normal conditions, and afterwards you have learned some more. We can't repeatedly create the same software over and over again altering just one factor and analysing the efficiency. In RAD Races you have different teams competing to create something working and useful, but the teams are constituted by individual members whose skill and motivation can vary by a large extent. Statistical approaches with many parties, contributing results over a long period of time could also be a good possibility, but getting objective and impartial data would be difficult. Further more the vast number of possible values for the vast number of parameters is way too large for any kind of exhaustive analysis.

If productivity is rising exponentially over time, it can be very difficult to pinpoint the most efficient approach. Getting stuck in a local optimum is very easy, and that is in my opinion the biggest problem for many organisations today.

A. A.

Tuesday, July 18, 2006

What is efficiency anyway?

Efficiency can be defined as the ratio of output to input for any given system. A better explanation could be skillfullness of avoiding waste. Google has a lot of other definitions as well.

The strictly economic aspect of efficiency is not always appropriate, although there may actually exist people who think so. See for example Efficiency in Art as an illustration of what i mean. I would argue that we need to take a broader view of what constitutes efficiency in software engineering. Clearly economic aspects are important, but suitability of functionality to the need as it changes over time should be considered more important.

An other problem with stating what is efficient in software engineering is that it is very difficult to draw the line of what is the boundary when you measure input and output. Some waste today could turn out to reduce waste later on.

If you draw your boundary too tight, and just focus on the next object or line of code you need to write, you can easily get stuck in local optima, which probably is very far off from the efficiency limit. If you make your boundary too wide, and try to embrace the world you will not either end up with a very good end result.


A. A.

Wednesday, July 05, 2006

Is there a limit to what software can do?

Grady Booch wrote an article for Rational Edge a few years ago explaining the physical limitations of what software can do. The article is still available, but now on IBM developerWorks (http://www-128.ibm.com/developerworks/rational/library/2082.html).

To kind of summarize, there are some things in software engineering that are possible to achieve and some that are impossible. Of the possible ones we currently know how to achieve some while we have no clue about the rest. Of the ones we know how to achieve, some we can actually afford to, while other are too expensive to achieve, leaving in between a grey area where we can either make a reasonable estimate or we will be able to afford in a year or two. We are also likely to be restricted by our management and organisations further by imposed rules and regulations to be followed, some for a well motivated reason, others for more obscure beliefs.

Further more, we unintentionally add errors and magnify any uncertainties in our understanding of the requirements. Some of the tasks in SW engineering are also are less motivating than others, further making the end result more uneven.

I somehow don't think that the hard limits to software engineering efficiency are anywhere near. I feel that the way we go about doing things are not anywhere near the level we could achieve

My intention is to further describe what is limiting our ability to solve IT related problems
as efficiently as possible in upcoming posts to this blog.