Efficiency Limit

Null results

2009-01-25T04:41:00.008Z

Presenting novel ideas is seen as valuable in our scientific culture today, but investigations of what the boundary conditions or side effects are more hard to find. Research programs are started to find and establish new theories, but not too much appear on under what conditions those teories does not apply any more.

Nassim Nicholas Taleb states it quite well: "you cannot do anything with knowledge unless you know where it stops, and the costs of using it".

In IT not much effort is put into understanding the down sides the "improvement" will have. One way of seeing this is that it is not in the interest of the IT staff or managers to know the limits, since that could mean less work since if side effects were well understood, the people making the investment may not be all that willing to back a number of projects any more.

Cost control

2008-12-31T18:08:00.009Z

IT is not the only area where projects are in trouble according to an article in the January 2009 edition of Scientific American that arrived in my mailbox.

NASA also seems to have trouble with the Mars Science Laboratory project. According to the story costs were underestimated and unrealistic, and there seems to have been a lack of will to keep costs under control. In contrast to normal projects where you calculate a return of investment and you can find a limit to how much you should invest, i don't think it matters what the cost is in the case of the Mars mission.

With IT projects there is often no abort button easily at hand for projects going over budget. In NASA however i would guess that the situation is a bit different. When promising the moon, or Mars as in this case you may end up having to deliver at any cost. Wherther it will succeed to deliver on the promise or not we will have to wait and see.

Understanding management

2008-11-29T11:51:00.004Z

According to a study management is struggling to get their message across to the people working for them in their organization. Among the around 200 mid level managers interviewed 87 % feels that the strategy is not being understood. Obviously this cause problems for the organizations probably impacting even the profitability.

One other way of interpreting this is that 13 % of the managers use normal language in stead of the normal jargon filled talk that management consultants and managers use. The study however did not present any data from which we could guess if the managers themselves understood what was being communicated. Still another possibility is that the 13 % or more of the managers have misunderstood how their people understand them and just describe the worst.

Seems like this should be a good research subject for further inquiries. For improving efficiency of management this could be useful. However, I don't think that the managers will change the way they communicate, even if this was shown to be the cause.

Efficiency of bureaucracy

2008-10-31T19:20:00.004Z

Under some conditions efficiency can be impossible to achieve. For example in an article by Dr Anthony Berglas one can find the surprising fact that costs for maintaining the australian tax office hasn't changed in terms of percent of the GDP per year over the last 50 years. Sure the tax office nowadays have more computer systems. This automatization has however just increased the complexity of the tax process, not decreased the amount of human effort. 50 years ago the regulations governing taxation was one order of magnitude shorter. Same seems to have happened with banking.

I find it good to know that even bureaucracy cant grow without bounds. For a tax office budget, anything below 2% of GDP seems to be acceptable to society, and the organization will try to grow until that limit. Growing would mean adding complexity to the bureaucracy, and hence also complexity is limited. Without a limit on the complexity or too much money to spend, there will be real big failures ahead.

Weekly dose of IT related problems

2008-09-30T16:25:00.007Z

According to news here in Finland every employee uses 53 minutes every week on average for solving IT related problems. Taking into account that some of us do this for work, and others even seems to work to create problems with IT i'm surprised the figure is not bigger.

The figure comes from research commissioned by Microsoft and performed by TNS Gallup in small or mid size finnish companies. The original press release can be found here, if you are interested and know finnish.

What the press release brings forward as noteworthy is that of the 22 % responders saying that they experience lots of IT related problems, being among the smallest and newest companies around, e-mail and office programs was causing most of the problems... The research however fails to state how many of those experiencing the problems use Microsoft products already or if there is any correlation.

One hour a week is reported to be a significant number. In Finnish small medium size companies that hour translates into 340 000 man days wasted per month as reported in the press release. That number seems already big and frightening, but in reality it is perhaps not all that much. 53 minutes every 5 days is 636 seconds per day, or between 10 and 11 minutes a day, that does not sound that much, or? Comparing 636 seconds to the 27 000 seconds spent at work every day is not a big deal, its just 2,4 % of the time.

Lets try to verify the calculation... Research stated that IT problems causes people to user 53 minutes every 5 days, fair enough, that would be 636 seconds per day. Assuming that every month has 21.5 working days, in reality it will vary between 19 and 23, depending on month and what kind of days off we have during a month... So, if we take 636 seconds, times 21,5 days per mont and multiplies that with 717 000 people working in the small medium size companies according to the source mentioned in the article, we get 9 804 258 000 seconds wasted per month, which sounds big. if we divide by 60 to get minutes, and further by 60 to get hours and again with 7,5 to get days i arrive at around 363 000 days wasted per month. Well probably the researcher calculated this some other assumption, perhaps taking vacations or holidays into account... Figure is well in the same ballpark.

I guess this could be compared to overlong coffee breaks, lunch breaks and other breaks with the difference that experiencing IT problems is not fun. A motivating work atmosphere was however mentioned as the most important factor making people efficient in their job for 95 %. Perhaps having long coffee breaks and lunch breaks or whatever gets the motivation into the work place is what we should consider. I guess workers simply compensate for the time taken by IT problems to some extent.
The research does not state how much of that time is unpaid overtime. Im however somehow doubting that Microsoft selling more Exchange or Office would decrease the time spent dealing with IT related problems in small or midsize companies. I feel the real issue here is the frustration and demotivation experiencing IT problems is having, not the time spent as such.

Estimating risk

2008-08-31T17:55:00.003Z

Humans are not very good at estimating risks. Our life seems to be more focused on estimating medium size risks such that we need to avoid every day. Small risks can be seen as unproportionally big, or big risks can be seen as negligible.

Risk of events occurring more or less frequent is seen out of proportion. A risk occurring with low frequency will however be common if the number of possible situations where the risk can occur is very big.

Ending project failures

2008-07-31T18:32:00.002Z

Seems like the idea of killing off projects looking like failures early on seems to be catching on according to recent blog entries like this one from Michael Krigsman.

Cancellation should however not be the primary mechanism for controlling projects. Every project should first be designed to succeed. For some projects only constraint given is a time table and a wish to either succeed or fail on time. Applying a cancellation to a poorly initiated project like this may not be the right thing to do.

Just because killing off a project was the right decision at one time does not mean that it is right to kill off every project in trouble.

Doing what you know or doing what is right

2008-06-29T08:34:00.010Z

Often people do what they are used to do, without any reflection. If it has worked once people tend to hope it will work again. Stopping to think and gathering and looking at evidence is often ignored in favor of doing the normal thing. Since conditions will vary, what was done previously may not be the right thing to do.

When you are hired you are asked for experience, measured as number of years working with a given technology, indicating that you are expected to do the same over and over again what you are experienced at, regardless of what the conditions are.

There is also a second kind of experience, where you have seen lots and lots of different things and you know that doing what you are used and expected to is going to go in the wrong direction. There may not always be very much you can do the improve the situation.

A better approach would be to practice an evidence based approach. If there are no evidence, you need to first run an experiment in order to obtain the data needed to make a sound decision.

Efficient architecture

2008-05-29T20:55:00.005Z

Architecture should not only state how parts relate to each other. Architecture should also describe the forces at work and how the particular tradeoff manifested in the selected architecture has been reached. Further more, information on what options has been discarded and why can be more valuable for understanding the solution than any description of relations.

In my opinnion architecture is about communication of the desired and undesired facets of our IT systems. A obscure arbitrary stack of boxes in a powerpoint picture does not realy provide all that much insight.

Presenting numbers

2008-04-24T17:58:00.002Z

According to an article in Journal of Extension numbers are understood differently based on how they are presented. Apparently percentages or simple frequencies (1 out of 10) are more intuitively understood than a large absolute frequency (or number like 5 million each year) even though the information is the same. For indicating a small thing an absolute frequency will appear greater in magnitude. Hence an absolute frequency may appear more persuasive.

Personally i prefer using graphs which can convey both kind of information at the same time, as long as the graphs does not get too crowded or too simplistic.

Benefits from ignorance

2008-03-30T07:25:00.004Z

There seems to be more to the saying "No news is good news" than one would first imagine. In a recent paper titled "Influence through ignorance" two researchers named Isabelle Brocas and Juan D. Carrillo suggest that peoples decisions can be influenced simply by controlling the availability of further information. When no new information becomes available current views will hold, even though absence of recent information should signal caution. The decision maker wishing to influence (or sales man?) can then, when he has the suitable data to verify his view, simply stop investigations generating more data. If generating the data is expensive, complex or in some other way highly regulated, the chances are good that the decision maker/sales man will get away with it.

I guess this can also help explain some reasons why some poorly suitable IT systems are obtained by customers. Since NDA:s (non disclosure agreements) ensure that information is not freely passed on to the public only the message from the vendor is publicly available, and it is most certainly not in the vendors own interest to make negative information available for potential customers. On the buyer side all information can be argued to be valuable, since it gives the rational buyer more sound picture of the product to base the decision on. Some buyers will choose to disregard all information and just go for the decision, like a predator attacking a prey, but nothing can help them. We others can perhaps better try to estimate what the "silence" or "no news" being given us means with this model in mind.

Quantum computing

2008-02-27T20:02:00.004Z

In the recent issue of Scientific American Scott Aaronson has an article presenting the features of quantum computers. It turns out that although there are certain things that such a computer would be able to do very efficiently it will not be able to solve all NP or NP Complete problems.

Factoring large numbers is however something a quantum computer could do efficiently. The author believes that this will be primarily application of quantum computers will be in physics for making more precise calculations of quantum states. Hope he is right, but i fear that the big monetary rewards for cracking cryptographic secrets used in e-commerce and banking may well be the target in the long run. Once a commercial quantum computer device would reach the market it could render current cryptographically secured data open.

I might be too pessimistic. I remember discussing this with a colleague involved with banking systems at a conference just after reading the paper by Peter Shor around year 2000. My colleague did not think that it posed any real threat although I'm not fully convinced that he ever understood the implications. I would however hope that my e-commerce transactions are kept safe in the future also no matter what devices become available.

Aquiring knowledge outside the box

2008-01-24T17:24:00.000Z

For many people it seems to be difficult to pay attention to information that is not matching their existing beliefs. Even if you are able to search for anything and find an abundance of correct information on the internet you may simply choose to ignore what is not according to your view.

Researchers from University of New South Wales have found that providing people with the right information on its own does not seem to be enough. As one of the researchers, UNSW Professor Enrico Coiera states: “Even if people read the right material, they are stubborn to changing their views." The study was conducted in the area of health, but i would agree that this is true in most disciplines, especially in IT.

In order to avoid being stubborn we need to constantly question our beliefs, and keep an open mind towards new ideas, but evaluate them in a skeptic way. The real difficult part is however to be able to know what to look for if your beliefs and world view is biased. Only remedy i can think of is to obtain and interact with information from very many disciplines and views, even if the information is of no apparent use, and this way at least become biased in very many ways.

Lerning by imitation

2007-12-05T20:08:00.000Z

Children seem to learn by imitation according to an article by Derek Lyons et al in PNAS. I would go further and say "So do I", a lot.

When imitating he argues that children cant tell which actions are necessary and which actions are irrelevant to achieving the goal, easily resulting in something he calls overimitation. Seems like there is no skeptic filter screening actions being imitated, although children would otherwise be able to identify irrelevant steps as silly.

I guess this occur a lot in IT (among other disciplines) as well. Part of what is done has no real relevance to the problem at hand. The procedures just happen that way as a result of accidents being replicated and accidentally frozen behavior, just because someone happened to originally do it that way. Somebody may finally realize that some parts of procedures are not bringing any value and improve, but that seems to take ages.

Working from home

2007-11-20T19:21:00.001Z

According to an article in Journal of Applied Psychology it is beneficial both for individuals and companies to arrange for telecommuting.

As a occasional telecommuter i agree that being able to work from home once in a while has positive effects for my personal well being and probably also for my employer.

The authors conclude with the statement that:

there is a downside of higher intensity
telecommuting in that it does seem to send
coworker (but not supervisor) relationships
in a harmful direction. Some of the
complexities of these consequences have
yet to be explored, but the evidence and
theory reviewed here suggest that they can
be managed effectively through informed human
resources policies.

Certain software development methodologies (like XP) rely on close interaction with both colleagues and customers. If you are supposed to do pair programming it will not work if the other person is working from home. Perhaps in the future someone will figure out a tool with which pair programming will be possible over distance, who knows.

A practical way would be to ensure that people still meet often enough for the necessary exchange and feedback too occur and adopt for example some instant messaging tools, although a tool can not replace the real thing.

The study does not directly compare what type of work you do and what kind of feedback mechanisms there are in the workplace or what tools you have access to. I would however guess that as long as the feedback keeps coming it is possible to be as efficient from home as anyone in the office.

Useless policies

2007-10-22T18:08:00.000Z

Some laws, regulations or policies can be very well motivated or self evident, but others are more difficult to motivate. The policy may for example be a legacy from an earlier era or issue that has ceased to exist. Other are just based on wrong assumptions from the start, perhaps invented to locally optimize some aspect in the organization at the cost of the whole. Bad policies can also be the result of corruption or ignorance.

But what happens to policies that is not current any more in your organization? Typically it seems like they at some point stop being enforced. A policy that is not being enforced is kind of useless. I would further more say that it is even more damaging to society or the organization at large, since it can undermine the trust between individuals in the organization. "If one person can break that policy why can't i, break some other policy?" seems to be the reasoning...

The efficient way of dealing with bad policies would be to just admit that the policy and the policy maker was wrong. In society bad laws are replaced by newer laws eventually, but within an organization it may not be possible to have that kind of overhead. Motivation for the policies should in stead be made clear so that spotting wrong assumptions is possible and enabling corruption to be ruled out as the primary reason for the policy. I wonder if this could actually happen in IT...

Agility and Scrum

2007-09-28T18:29:00.000Z

I was recently listening to some presentations from a conference hosted by the Belgian Java User Group BeJUG on http://www.parleys.com/. There are at least four excellent presentations that i hope people would listen to.

Kevlin Henney has two presentations dealing with different aspects of being agile (part 1 and part 2) dealing with the necessity of getting feedback and adapting to change when attempting do undertake IT development.

Giovanni Asproni also has two presentations (part 1 and part 2) explaining how Scrum works and can be adopted, and under what conditions Scrum will not work.

Risks and management

2007-08-28T18:59:00.000Z

Recently i read John Scarpinos column How poor management skills jeopardize software quality dealing with willingness to take risks, fear and lack of communication within IT and a fascinating article in Evolutionary Psychology titled Towards the development of an evolutionarily valid domain-specific risk-taking scale by Daniel J. Kreuger et al.

In business today taking risk seems very attractive to management. Taking a certain amount and type of risk can bring a competitive edge to the manager. The manager willing to take the risk can, if he succeeds make a better result than his colleagues, giving a better opportunity to become a more prominent manager in the future. Somehow it seems like business today is not too different from what evolution has wired into us over time when humans were hunters and gatherers. Fear is in a sense a very normal feeling, i suppose our ancestors were both afraid of the animal they were hunting and of starvation at the same time. Only thing is that today we today seems afraid of managers and failure to get a good result.

I'm sure that at least in some domains there is value to a very rigid Quality Assurance process where by risk is minimized, but i don't subscribe to the idea that QA should be allowed to interfere with business risk taking or innovation. What i more consider problematic is first of all the trend by managers today not to be present taking responsibility for the risks taken when things go bad or not sharing the benefits from the risks taken. Evolution should however have given us the ability to deal with cheaters since this is neither any new kind of behavior... Second problem as i see is that managers don't know or either want to know what kind of risk they are taking. This can be related to a basic lack of communication or lack of presence of the manager. An other way of viewing the problem is that employees out of fear or whatever hide unpleasant issues from their managers.

Managers ruling by fear and authority do however have one significant disadvantage, since they are not likely to get anywhere near a full set of information to base their risk taking on. I would even go further to say that strict formal process oriented approaches will always come second to managers participating in a dialog as equals, being present and acknowledgeable and fair in their actions. Knowingly taking small affordable risks can give great rewards, and if things go bad, just use plan B.

Challange of introducing ideas into orgainzations

2007-07-25T20:08:00.000Z

Bringing in consultants are often seen as a way of introducing new ideas into an organization. According to a new study done at Warwick Business School this however seems to be misleading.

It seems that managers bringing in new people hire someone like themselves. Any new idea or person introduced will not be accepted if the new person is to unlike the manager and the others in the organization.

The problem is that if the organization gets too similar there will be no diversity and very little difference of opinion, and changes needed may not find a place to evolve. If everybody is of the same opinion there is a great risk that good ideas and opportunities will be lost. Without new ideas there is likely to be stagnation while competition is evolving.

Inside diverse organizations on the other had there already exist a multitude of novel ideas that can be used. What the consultants specifically can do in a diverse environment is to bring ideas into attention. In a non diverse environment there is not very much of a possibility of introducing anything and the only thing left to do is execute whatever is planned.

Half of all IT projects late according to HP studdy

2007-06-18T08:33:00.000Z

In todays Finnish language business magazine Kauppalehti there is an article citing HP research, stating that one out of two IT projects are late. Also one out of two projects are stated as being over budget. The main reason given is that coordination between IT and company management is lacking, outsourcing is failing and to a lesser extent changing or unclear requirements and a lack of resources. The research was compiled based on questions sent out to a large number of IT executives. However, the answers obtained to be over optimistic and that a change made to the time table for a project is not reported as being late. A better estimate would according to the article be around 90 % late / over budget.

What is interesting however is that the projects being late has a direct impact to the profitability of the companies. I would say that this sounds like the ideal market condition for consultancy and outsourcing vendors, whatever goes. I wonder when management is going to start taking interest in where the IT money is spent and why the promised returns of investment is not showing.

Further more management seems to be unable to do anything about the situation. Decreasing scope and increasing number of people on the project are the most common way of reacting to a problem in a project. Only one out of five confess to sacrificing quality over timetable, the rest probably never intended testing anyway or are too embarrassed to admit to this. Adding additional coordination will probably only add to the over all cost without any significant improvement in project delivery.

Learning from uncertainty

2007-05-29T19:18:00.000Z

It seems easy to know what caused any failure afterward. At least it is easy to come up with theories of what have caused any given failure. Problem is that there is often no way of verifying the causes. Predicting into the future just seems impossible.

In medicine we have clinical trials where drugs are given under very controlled conditions, some patients even getting a placebo as replacement for the real drug. In IT this would be difficult to arrange.

IT is a field with lots of uncertainty involved. Some things will work sometimes, but not always. A successful setup in one project may lead to a big time failure in the next. A setup failing in one project may work perfectly in the next. There is no way that you can beforehand know if you will have positive or negative surprises and if they will impact your endeavor at all.

Only fool proof way to safeguard against unpredictability seems to be to progress in small scale steps, failing early and not in an expensive way. If we are allowed to try enough times we will eventually succeed.

There is an excellent Tech Nation interview with Nassim Nicholas Taleb dealing with unpredictability and impact on business available at ITConversations, go check it out.

Learning efficiently from failures

2007-04-30T09:06:00.000Z

There does not seem to be very many lessons to be learned from sucsessful projects according to an article in IEEE Spectrum. From failures on the other hand you can always learn a lot.

Being efficient, you should at least try to learn from your own mistakes. On an organizational level it would make sense if everybody was able to learn from all mistakes done in the whole organisation. On a global level it would make sense to try to learn from all mistakes evere made. Access to information is however limited, and there is probably not enough time to get familiar with all failures in your domain.

If you cover up the mistakes, chanses are that somebody will have to experience the same problems again. Opening up your experiences for other to learn from can help others in your organisation to become more sucessful. Getting comments and feedback from others will further more make you see more clearly what the the problem was and even come up with better solutions to avoid similar problems in the future.

However, nobody likes to admit failure. I think organisations must become more able to accept and tolerate small falures, and start to encourage people to learn from failure in stead of covering up. If failures are detected and admitted at an early stage there is time to prevent the big failure that probably is lying ahead. Big failures are anyway difficult or impossible to cover up.

Efficient frameworks

2007-03-30T05:30:00.000Z

Using complex frameworks are often motivated by increased efficiency. Some things are however inevitably complex.

Real time thread synchronization across processes and machines is for example hard. You have to avoid dead locks, make sure that your processes yields execute threads in a predictable manner and guarantees execution of all tasks on a given time. Getting all this correct is not easy, not even for experienced developers.

Frameworks are motivated that they make hard things more simple. A common problem is however that they only enable you to shoot yourself in the foot more efficiently, which is most often not what you intended to start with. In order to utilize the framework efficiently you need a thorough understanding of the underlying problem domain and also be able to solve the problem in terms compatible with the tools and possibilities the framework gives you.

Most frameworks are not developed with your problem in mind and general purpose frameworks are most often too generic to be useful. If your need exceed what is intended with the framework of choice, you end up adding more complexity than you would need without the framework.

Complex tings can be made to work, no doubt. For one time fixes, in order to get something working in a quick and dirty fashion the additional complexity does not matter very much.It is just a one time penalty to pay. The trouble starts when modifications are needed, since somebody must either remember or figure out how it works, probably from the source code, which may or may not conform to any pattern or convention.

People in general tend to fall in love with their framework of choice, If the framework suits your every need, there is a benefit if all developers on the project like working with the framework. However, if the framework does not fit the problem you are going to have a tough time ahead.

Crippled by design

2007-02-12T19:39:00.000Z

Designing optimal solutions is difficult. Settling for a working solution is every day life, but most IT solutions seem to get seriously crippled in one or more aspects at some point in time. The system can be difficult to use, costs of development can sky-rocket, it can be impossible to maintain, it can have limits in scalability. But even crippled software can be useful.

There is probably no single one and only explanation why this crippling is happening. I'm sure that many causes combine. Many of the problems giving the system a crippled appearance can be fixed, given time and resources, but there always seems to be new issues popping up, like peels on an onion. Some times a crippled system delivered today is better than the most optimal system delivered too late.

Generally it is said that it is cheaper to fix a problem that would cripple a system early in the design phase. The problem with this is that early you don't necessarily know every aspect that will appear crippled, even how thoroughly you look at your design. It is just no possibility to know every aspect of how the system will appear before it is actually deployed into production. There is some value to the design up front approach, but on a too detailed level it is doomed to result in analysis paralysis.

When designing software and IT systems there are more degrees of freedom than can be perceived. You can implement a system in many, very many different ways. Most ways of implementation will not differ very much from each other when done, and most will have no influence on the end result, but each possible equal implementation can be given a most important role due to decisions made very much later on. Reversing the latest decision can sometimes only bring negative side effects. Going back and undoing the faulty decisions, made long ago, is not always the most pleasant thing in a normal project setting, but in agile projects doing refactoring this is actually one aspect that in my opinion makes agile approaches better, if only the faulty decision is found.

Real clear failures are just as rare as optimal solutions. Mostly the reason for failure is that projects run out of money. With agile approach there is a natural way of closing down unsuccessful development work. Perhaps we should be ready to scrap and abort more traditional software projects also that are showing signs of crippledness. I think that even the most severely crippled IT system has some value in that it can teach us a lesson perhaps enabling us to doing better next time. The most important thing to remember is that it is your actions as a designer, either the ones that you do or the actions that you omit doing that is going to make or break the system. There is no escaping, you are responsible for your design decisions.

Measurement and feedback

2007-01-23T19:52:00.000Z

The preoccupation with measuring every aspect of IT efficiency seems to be ever increasing. It seems like there is no limit to what piles of rubbish management and their followers are trying to collect in order to find the one measure that will tell them how their organisation or department is doing.

The problem is that there are lots of things you can measure, and some may even tell you something about the actual performance, but most measurement seems to be a waste of time. Some measures are too abstract to be of any use, like "rate of success". Others are just too detailed to be useful, like lines of code written per day.

In my opinion you can spend your time better by arranging for your teams to have feedback loops in stead of figuring out new and better measures. The shorter the feedback loops the better, since if things change quickly you need to react quickly. With sufficient feedback you can be fairly sure that you are doing the right thing, or else you will know about it quickly. There are numerous examples from nature where feedback loops regulate and interact in order to steer processes and their outcome, examples ranging from metabolism to neural activity.

One of the keys here is that the sensors in nature are integral parts of the process like for example proteins catalysing the conversion of one substance to an otherbeing inhibited by the end product and stimulated by the raw material. The centralized control seems to be kept to a minimum, and only exercised as a means of giving over all direction, so why not mimic the same in IT?

Empowering everyone to make sane decisions based on feedback, or even listening to feedback at all must feel threatening to management accustomed to safely measuring and them self interpreting the result. However, if what counts is the end result and over all efficiency, the score seems clear.

Cost of features

2006-12-28T20:02:00.000Z

Microsoft seems to be hitting their head in a wall with the new Vista content protection according to a very interesting report by Peter Gutmann.

If the actual implications are as fatal as what is stated remains open to see, but a conclusion we can make at this point is that not all end results can be known beforehand when designing an extremely complex piece of software like for example Vista.

There is no way of knowing how the software/hardware ecosystem will be affected by a gigantic release with lots of new unknown features/traits. Transparency can help, by making the design and implications visible early, but there is naturally no guarantee that anybody will spot the problem before it is too late. Also, afterwards the problem must be acknowledged and corrected, requiring a fair degree of openness.

This time it seems like bending far over in one direction has resulted in a large invasion of problems from an other unwelcome direction. It is very unfortunate and disturbing that the focus does not seem to be set on making real customers happy, but more on satisfying digital rights owners unspecific dreams.

Openness, transparency and efficiency in IT

2006-12-21T05:20:00.000Z

In Open Source - More Than Code Bill Barr discuss if you really can run IT efficiently while maintaining full transparency to stakeholders. I have also been looking at the effects of transparency.

The spirit of SOX for example seem to require that business have full visibility into everything going on, down to a very technical level. In my opinion business should. First of all, they are paying for the IT systems and their development. Secondly, the more involved they become the bigger is the opportunity that the IT system serves the business need. Following SOX and other rules can then just be seen as another minor reason for driving transparency. Extra paperwork and meetings is often seen as a main drawback, and with the sad state of documentation I have seen on a number of cases this is most certainly true, but not in my opinion valid, since there is usually some value in improving documentation anyway.

The problem with transparency and involvement starts when business stakeholders interpret this as a mandate to lead and manage the IT development. This often result in micromanagement, having everything grind to a halt. The problems may be small or big, but in the end they all depend on the personalities and driving forces of the stakeholders you are working with. Keeping these stakeholders in the dark is often seen as a solution, but that can create even more serious antagonism further down the road. I think that a better solution is to make them aware of other stakeholder views and needs, in terms of costs and business risks, and the fact that they may not necessarily have all the facts or the knowledge required.

I would not say that transparency or openness need to be in conflict with efficiency, but there is a good chance that they will be. In a deep hierarchical "chain of command" type organization where departmental silos are not discussing with each other I think you can have either openness, transparency or efficiency. Achieving any two in any combination would come at an extremely high price, and all three is probably next to impossible achieving.

That said, I still consider involvement of individuals, openness for change and transparency to what is being done as the key to efficiency. The individuals in a lean organization, once set with a task, may well know how to achieve a solution as long as the organization is truly open to this kind of involvement. Transparency guarantees that if some initial condition change or some theory is later found wrong, there are plenty of opportunity spotting and correcting the error. The key i think is that everybody need to agree on what the actual problem that is to be solved is and listen to each other.

Improving efficiency is easy to if you don't need to consider any side effects. In the end, IT department efficiency should not be considered as the ultimate goal, and trying to optimize on a project or code development level can in worst case only reach a local optimum. Optimizing for business efficiency would be far better in many cases.

Knowledge for public good?

2006-11-06T20:00:00.000Z

I would agree with Gowers review of IP (Intellectual Property) report that public good should be considered over private rights. I guess somebody eventually will take the time to sit down and plot out a chart of the solutions to the problem, as a function of public good, private profit and the good that can bring over time of a set of different IP types, but that may not be all that useful.

The biggest problem with the IPR legislation as i see is however that the law and the public perception of what is right is diverging. I would say that the damage to coming generations perception of right and wrong simply cant be corrected if that situation is allowed to continue.

Both society and coorporations would in my opinion benefit the most if knowledge and IP works of any kind truly were open for others to mix, match and blend withingiven limits that everybody were ready to aknowledge.

Openness and efficiency

2006-10-08T16:59:00.000Z

What is the point in keeping new innovative ways of working secret?

Some state that it is not any single idea, or any kind of secret you hold that is the key to success, but hard work. People would very much like the opposite to be true, since that would mean that they don't need to work their butts off, but can sit back and relax while somebody buys their idea. That is however seldom the case. You realy need to work hard in order to do a better job than your competition. Most of them do a really lousy job anyway so it should not be all that hard, and the rest never understood what it the idea was all about anyway...

However, secrecy, internal competition and the "secrecy cult loving" corporate climate seems to have got the better of efficiency in today's world. Patents, non disclosure agreements, licenses, information on need to know basis and lawyers all help holding this cult of secrecy in power. Does it really make sense?

Nature teach us that individuals die and the knowledge they have acquired with them, but species survive. Other individuals in the species pick up some of the ideas and transmit them further. Holding secrets is not very smart in the long run with the knowledge that the individual will go under in a short while. Ideas can only be saved by copying them. The more copies the better. If there is a short term benefit to be gained from keeping secrets it used to be profitable only for a short time. In the long run somebody always came up with a better idea. With the prolongation of the patents life and copyright this is perhaps not the case any more.

Organizations and individuals should in my opinion at least be open to new ideas. There is a saying that innovation happens elsewhere. I tend to think that this is very true for major new ideas, since organizations and individuals inside the organizations get used to defend their own position and focus on minor improvements that can be done without disrupting the stagnant state the organization live in. If organizations are closed to new ideas then they will in the long run be doomed, which should however perhaps not be seen as a bad thing. Something else will follow after a major failure.

Openness also implies sharing. You have to give something in order to get something. I think this is also true when sharing ideas. If you only listen you will be able to understand something, but the comments you get from sharing what you do can be very much more valuable.

Some laws however set limits on the openness an organization can display and what can be shared. Health records or other personal information can not be shared without serious risk of violating the law. Openness can generally not be targeted at only one subset of the organizations peers, but must be equal to all. The law however still leaves plenty of room for sharing, openness and learning from others for any organisation to become more efficient.

Are "best practices" really any good?

2006-09-29T18:27:00.000Z

Why did somebody pick the term "Best Practices" to describe something very often constituting a local optimum in efficiency space? I find it very hard to believe that all approaches described as "best practices" are equally good or even fulfill the label "best practice" at all. Lets for example examine two approaches that seems to be fairly popular, and seem to at least think they represent "best practices". The first, patterns, is fairly technical in its offering and close to the code while the second, ITIL is more management related.

Patterns have a clear area where they are applicable limiting their scope. Patterns are can be used, copied and most importantly improved by anyone. Patterns are in a sense open for improvement. Patterns seems to have spread rapidly to use into real life applications, some patterns obviously more than others. Embracing patterns has been made fairly easy. Inefficient code can be reimplemented using patterns by a technique called refactoring. Some tools are even claimed to automatically refactor for you at the press of a button.

ITIL is described as a collection of best practices, but is it really as efficient as it can be? I would state that it is too early to say although ITIL has been around for some years. ITIL is however only in the process of being broadly adopted. ITIL seems more proprietary and does not seem to welcome feedback to the same extent. This limits the people working on improving the offering to only those that work for the agency. In stead ITIL seems more focused on providing training and certification at a price. Migration to using ITIL processes is left to the organization perusing excellence. ITIL also seems fairly vague in terms of limiting applicability.

A "best practice" should logically be something that is coming fairly close to being as efficient as possible. Many patterns fulfill this requirement. ITIL i would say is a good practice, at least in some respect, but in others seem fall short of being a "best". I don't think the difference in technical dept between the two examples i picked is fully responsible for all differences.

Some are often baffled by the fact that a bureaucratic approach like ITIL is even considered a good approach. Everything however depend on the problem you have at hand. If you need to only manage a single server used for a non critical application used by a single user to serve his own blog entries ITIL is probably just as overkill as writing this application using every existing pattern ever documented. For a major fortune 500 enterprise in Europe ITIL may however be a very good approach to fulfill legally mandated governance of financial applications.

What i mainly disappointed in is the failure of "best practice" promoters to recognize and efficiently communicate the known limits. One major key to efficiency in IT lies in knowing what is suitable. In a similar way one of the major reasons for failure is belief that one approach would be suitable when it in reality is not. Marketing seldom gets the limit across. In the mean while until there is a non subjective declaration of content for each approach the best solution is to be skeptical of all "best practices" and carefully evaluate their merits. And yes, i would prefer that the "best practice" promoters would in stead start to talk about good operating practice.

Efficiency in IT

2006-09-14T09:08:00.000Z

Defining efficiency in IT is harder than defining inefficiency. Inefficiency could for example be defined as when resources/time/effort is wasted in IT functions.

There is nowadays much talk about efficiently aligning IT with business. IT functions should be getting the right things done in an agile manner as requested by the business. There is some merit to this, but mostly its just empty talk. If business have no clue what they want, or if business have no way of communicating what they need you will not either get any efficient aligned IT function for your business.

You must to a large extent know what to do from all stakeholders point of view in a balanced way. Some unfortunately tend to understand that business alignment only mandate implementation of the often arbitrary requested features. Truth is that a successful efficient system must fulfill needs raised by all stakeholders regardless if they are business representatives, technical deployer or help desk support professional. Some requirements are more important than others, but letting one part decide on priorities is not wise.

This does not mean that ALL functional or nonfunctional requirements should be implemented. It is equally important to be able to disregard all not well thought out requirements. Featuritis is a dicease where often business are forced to prematurely state all requirements up front (as done for waterfall projects) to be sure that they don't need to be involved in any cumbersome change management process intended to limit changes more than fulfilling any other need.

So how do you know what to do? One thing you could try is to ask me, but ill just answer that I don't know... The key, if there is any, is to involve everybody in your quest for efficiency. This has been shown to work in factory settings, so it should work in any setting. The people doing the work that will be affected by the change should know what can be done better and where it will lead, but getting the ideas out into the open will take a bit more than just asking for comments in a email message sent to all. An other thing to rely on is experience. If you don't have experience you have a good opportunity to acquire some by trial and error.

An useful guide to efficiency is to keep the spirit of Occam's razor in mind, or try tp do everything as simple as possible, but no more simple. Excessive complexity leads to waste, or aspects that will never be used that will be in the way of further development.

Nature has a couple of important lesson for us to learn. Always start small and evolve from there. Kill of bad ideas often and early, before they become multimillion failures bringing the whole company down. Everything does not need to be perfect, just good enough will do. Interaction with stakeholders and suggestions for small changes should be welcomed at every opportunity. The ability to test out new small features in a cheap way without substantial risk can be one source of efficiency. Doing small nondisruptive changes quickly is why agile movement is pushing. Note however that any agile approach by itself will not guarantee efficiency.

What is a limit?

2006-07-29T17:41:00.000Z

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.

What is efficiency anyway?

2006-07-18T18:24:00.000Z

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.

Is there a limit to what software can do?

2006-07-05T20:59:00.000Z

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.