Jiri’s Notepad

It seems that this week has been marked by articles on size and comlexity. First, Financial Times (requistration required) introduced in a review of a forthcoming book on this topic:

Success fuels growth. Yet growth breeds complexity - more employees, departments, product lines and business units. Managing complexity diverts attention from the real work of business: attending to customers.It is not only small, entrepreneurial outfits that face this dilemma. Big corporations are now free to manufacture and sell their products in almost any country you care to name. In order to take advantage of the opportunities, however, they must work out how to manage the complexity that global growth entails.

Then, I discovered an excellent summary of a BCG paper on the EyetoIT weblog:

There are actually a couple of IT-related aspects when considering complexity, there’s the need for IT to support business-rule complexity and then the issue of the more complex systems that are created (and must be maintained) as a result of supporting the business complexity.The group actually points out the IT has tended to be an enabler for complexity. In many respects, technology is great for dealing with exceptional cases. However, the total cost impact of supporting so many exceptions is often poorly-understood.

One client of mine ended up building some customized tools to bolt on to their Tier 1 ERP product just to help automate the incredibly complex and customer-specific pricing management - and this company doesn’t sell a particularly high-margin product.

[…]

And because the system can support this, your account sales force is all of a sudden able to negotiate pricing on a line-item basis. Now, for a particular account, this may make great sense, but because the incremental cost of adding each pricing customization is so small, it is too easy to allow for such pricing variations when it is not really necessary. After 10 years of doing this, the company may figure out the costs of supporting the variability are too high and they will embark on a rationalization project. As anyone who has gone through such an endeavor knows: it is much easier to inject complexity into an operation than to try to simplify things.

Process is one of answers to the problem of scale and complexity. Yet, in practice, there are drawbacks to a process. It is way too easy to create a process-monster that then needs constant attendance and feeding. Microsoft’s Steven Sinoffsky has some good things to say on this topic in his blog entry Bureaucracy. Threat or menace?:

The baseline comparison for this, especially for college hires, is the “edit-compile-debug” cycle we’re all familiar with in college. You are the master of the machine. You have no dependencies on anyone else. You know every line of code. This is an awesome way to write code. It is also the best way to write projects that are the work of one person. Anything more than that and you have a dependency. At the same time, if you are working well as a team you can quickly have a 1+1+1 = 4 or better. The challenge is that you have to put in some process to make sure that you get the benefit of using each other’s code and the benefit of working as a team. It does not come for free. Putting in the right process is very hard work. It is super [sorry I used that word] easy to put in process that makes 1+1+1 =2. Process can sap the life out of a team. On the other hand, it seems absurd that you should be able to change “on a whim” the code of a system that is used by hundreds of millions of people-customers expect and demand that you have some process for deciding what to do. Anything of any material complexity must have that rigorous view. If it doesn’t then the system is a toy or the system just isn’t valuable.

Everyone who has built a software project knows that once you have customers you have an installed base and therefore you have to be careful about changing things. But you also have customers that come to expect features in a certain way. You have customers that might want to have say in how things evolve. You can’t just be an “enlightened engineer” and speak for every possible customer, every compatibility issue. It is likely you’ll need some help. Imagine for example, you wrote the code that decides what advertising to show on a web site (like we have on many sites at Microsoft). You have a great idea to make it better and make a change and check that in-but oops, you didn’t know that product management had come up with a clever, revenue positive, pricing scheme based on how different ads appear. You just changed the company revenue with that “flexible” development process. You then find yourself backing the change out in the middle of the night. Perhaps then the team will put some safeguards in place.

Once you put in a process that “slows” down that work there is now an official bureaucracy. So you have to minimize that so that people can spend the time they have doing the things they like-developing, doing marketing campaigns, etc.