Comparing work by cost only

A company I worked for recently stated that "the internal hourly rate has to be brought down to xy Euros" in order to compete with other companies. This argument was mainly made to emphasize the importance of doing more (cheap) work off shore, thus lowering the average hourly rate.

Somewhat concerned I looked at the sentence for a while, thinking about whether this might be hinting at an unpleasant development that could have implications for me as a freelancer (I never ever have worked for as low as xy Euros per hour).

Then I relaxed.

You only may compare prices for specific services rendered if you are talking about the same kind of service, "the same kind" as in "same amount of work done per unit of time" and "same quality". When buying a car you would never look at the price only: What make, what model? How old is it, what is the mileage, what is the condition?

Compared to German programmers, offshore resources only cost a quarter - on paper. In reality, the offshore partner regularly puts more people at the same task then the German side would. Some key people of the offshore partner will receive training on the project in Germany, and there will be a permanent on-site manager. So, add travel and hotel expenses, plus lost work time on the German and offshore side.

What if the customer doesn't like documentation in English, and the offshore partner does not understand German? Ka-ching, add cost for translation, and load your tolerance module for accidentally introduced errors. And then, oops, personal that was trained in Germany leaves the offshore partner for sunnier shores. In the end, the cost is closer to 75% of the German rate.

"75% of the German rate" still doesn't sound all bad. But this is for the development portion only. Sales, marketing, project management, requirements analysis, specification, design, testing, and roll out is all done in Germany. Development maybe is one third of the overall cost. In the end you would save about 8%.

"Saving 8%" is not nothing, right? Yes, but are you sure there aren't any other ways to increase productivity, which essentially means getting more bang for your buck? Offshoring means often has the side effect of alienating people working for you "at home", and IMHO offshoring is doing your local economy a disservice.

Why do people start with offshoring when they try to save money? When optimizing a program you start with an analysis first, identifying the code where most of the time or memory gets consumed. It is here that optimization effort gets you the greatest effect.

Blindly aiming for a lower hourly rate by using offshore resources is a brute force approach that does not look at underlying causes that drive cost up. There are quite likely easier ways to improve productivity then transferring work abroad. Analyze your cost structure. Start working on the biggest items first. Review you processes. Educate and cherish the people working for you. Try a little harder at home!

Quotes Related to Software Entropy

Many quotes I found at hackification, others are from "all over the internet":

Code For Humans

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. [Martin Fowler]

Programs must be written for people to read, and only incidentally for machines to execute. [Abelson / Sussman]

Instead of imagining that our main task is to instruct a computer what to to, let us concentrate rather on explaining to human beings what we want a computer to do. [Donald Knuth]

Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer. [Steve McConnel]

Design and programming are human activities; forget that and all is lost. [Bjarne Stroustrup]

Increasingly, people seem to misinterpret complexity as sophistication, which is baffling --- the incomprehensible should cause suspicion rather than admiration. [Niklaus Wirth]

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. [C.A.R. Hoare]

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live. [Anonymous]

A charlatan makes obscure what is clear; a thinker makes clear what is obscure. [Hugh Kingsmil]


Why Fighting Software Entropy Is Worth It

Conceptual integrity is the most important consideration in system design. [Frederick P. Brooks]

Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. [Frederick P. Brooks]

... with proper design, the features come cheaply. This approach is arduous, but continues to succeed. [Dennis Ritchie]

The need to minimize software cost] suggests that large-program structure must not only be created but must also be maintained if decay is to be avoided or postponed. [Belady and Lehman]

All repairs tend to destroy the structure, to increase the entropy and disorder of the system. [...] Although in principle usable forever, the system has worn out as a base for progress. [Frederick P. Brooks]


Attitude Adjustment

Writing code … is not an exercise in manliness. [Mark Hahn ]

Unformed people delight in the gaudy and in novelty. Cooked people delight in the ordinary. [Erik Naggum]

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. [Edsger Dijkstra]


The State of the Art

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. [Alan Kay]

No matter what the problem is, it's always a people problem. [Gerald M. Weinberg]

Experience doesn't necessarily teach anything. [Gerald M. Weinberg]


Somewhat Unrelated

Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. [Doug Gwyn]

The designer of a new kind of system must participate fully in the implementation. [Donald E. Knuth]

The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt. [Bertrand Russell]

Why Racing Probably Will Slow You Down

Many programmers will have gone through the following cycle.

The project time line has been tight from the beginning. Finally the specification gels into a vaguely discernible form, though pretty late. No time any more for architecture, design, and generally engaging the brain before typing. The deadline must be made! Everybody rushes to the goal, best practices and common sense are trampled into the ground, and hackers feel finally freed from those bureaucrats that call themselves architects.

Inevitably the project is late anyways, and the code is a huge mess that will be cleaned up when there is time. That is: never. Time is money; where should the money come from?

The customer? "Hey, the stuff finally works, why would we pay for beautifying the code? And, by the way, don't you guys advertise high coding standards?"

Your own company? "Well, the budget is blown, and the customer won't pay for it! And, by the way, aren't you guys using best practices?"

A good solution would have taken maybe 20 or 30% longer than the ordered estimate. In the end the project consumes the same amount of time. Additionally you get a much poorer result, angry customers, frustrated programmers, and the kind of code that makes you want to switch projects before the next release. Cutting corners when your experts beg for some time to think before coding will buy you nothing in the long run.

Suggested Reads

• "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin (Prentice Hall) - If I had a company this book would be a must read (and understand) for all programmers.
• "The Pragmatic Programmer. From Journeyman to Master" by Andrew Hunt, David Thomas, Ward Cunningham (Addison-Wesley) - If I had a company this book would be a must read (and understand) for all programmers.
  

Fighting Software Entropy - Intermediate

Recently I read an IEEE article on software metrics that identify potential dangerous constructs in code, such as brittle base classes. One short example: "Foo" declares and uses a method "bar()" that may be overridden by an extending class, potentially breaking functionality in the base class.

Metrics like this can really help to improve software quality. Considering the state of code that I see every day as part of my consulting business metrics like the one described above would be the final touch on top of a long list of measures and rules I would recommend to employ first. As long as methods with more than 200 lines abound, copying code is a design pattern, and "verifyOrder()" changes the delivery address in the data base you've got bigger problems to tackle first.

When washing your car you don't start polishing before you hosed away the mud - that would be spending a lot of effort in the wrong place. Getting rid of the mud takes 20% of the cleaning effort and gets 80% of the job done. When you optimize a program you first analyze where most of the CPU time gets spent and concentrate on these hot spots. Likewise, there is a rather small number of coding guidelines that go a long way to improve code quality.

Here is my hit list of the most important code improvements:

Nomen est Omen: The name should fit the meaning. Don't call a method "verify()" - the name strongly implies read only access - when the method changes data or even creates and deletes whole records in the data base. You don't like documentation? Well, choose good names; together with the next rules your code will be as easy to read as pseudo code. There is no excuse for bad names: refactoring has made renaming safe and painless.

One method, one purpose: If it is difficult to find a concise name you probably packed to much functionality into one method. Break the method in smaller method that each do only one thing, and make that thing the name of the method. Again, refactoring makes this simple.

Break down long methods and expressions. Introducing more local variables will not slow down your program; modern compilers will optimize execution better than you can (at least in this regard). Break down methods into smaller methods, too. You might even find redundant code that you can eliminate, or that methods become usable for other than the original purposes.

[This article is going to be extended]

Fighting Software Entropy - The Basics

In many companies code formatting and checking tools such as the Eclipse code formatter (or better: the cleanup function), Checkstyle, PMD, and FindBugs are pretty much the only measure taken to improve code quality. To continually use these tools is a very good measure - as long as one realizes code formatting and checking are the very basics of code improvement, not the pinnacle.

Through 16 years of professional programming experience I am certain that not tools and rules will create software quality, but genuine insight. In example, I worked for a large telco as a software architect. But instead of designing a system that, just as an example, decouples business logic from specific XML parsing frameworks through the use of domain data classes and transformers I found myself having discussions with certain programmers about the number of characters per line.

Some programmers were using expressions that extended over 200 characters and longer, and considered it their personal right and freedom to do so, as long as the code works. I disagree, since not only the compiler has to understand the code, but humans. Such an attitude neglects the rights and freedom of others, in example the right to understand the code of coworkers in a reasonable amount of time and the freedom to concentrate on implementing functionality, not having to reverse engineer cryptic source code first.

Sticking with the overy long expression example I maintain that nobody can intuitively grasp the meaning of such a monster. This is not how the human mind (specifically short term memory) works. So: Break long expressions down. Use refactoring to introduce methods and local variables. "account.isNew()" contains more information than "account.getNumber() == null" and is way easier to read and understand (and what happens if in the future accounts can be new and already have a number?).

Let us assume you are in a role that is supposed to improve software quality. Now, how do you create insight? The term "insight" implies that it is something that a person develops for her- or himself. It is nothing that you can forcefully create; it has to come from inside the person. You can try to foster insight, by appealing to having an open mind, showing good and bad examples, and providing positive feedback (eventually enjoying the results of a better programming style).

What do you do if all that does not help, and a programmer expresses his or her low opinion of the suggested programming style verbally, or worse, in code?

Well - I personally expect that professionals try to improve their skills all the time. Backed by the insight and research of others and by my own professional experience I have an opinion on what good and bad programming style looks like. I know what programming style means to a project in the short and the long term. As a developer I have often enought felt the anger, frustration, desperation, and hopelessness that comes with having to understand, maintain, and extend steaming heaps of code that nobody dares touching any more.

The difference in programming style and attitude is so great (measured by criterions such as less stress, higher productivity, more deadlines kept, lower cost, less overtime, and - yes, more joy!) that if I have the choice I'd rather work with programmers who employ a good programming style, and let the others go to work on other projects.

Mantras

[This article is going to be extended every now and then]

All Redundancy Is Evil

Really, if you can avoid redundancy, do it. If it costs some unpleasant effort, bear it - you'll get repaid later again and again.

Copy and paste is a surefire way to pain and suffering. It is very hard to see if different but similar code really does the same thing - you'll have to compare the two spots down to the last character. And when there are differences, are they the result of deliberate modification or some accidentally incomplete update?

If it can be generated, don't check in the product but polish the source (and, if necessary, the generator and/ or its configuration) and automatize the process. There are way too many projects where the results of some generator run have been checked in. After a few months nobody can tell for sure anymore whether the generated stuff has been modified by hand (and don't do that).

Don't "Unstructure" Information

Enterprise Architect, a very good UML modelling tool, allows you to attach RTF documents to an UML element (the tech term is "linked document"). I've seen projects where all information is in the RTF document, and none in the fields and links that Enterprise Architect generously provides (pre- and postconditions, scenarios, actors etc.).

Why in the world anybody would do something like that is beyond me - you loose all opportunities to generate reports (ensuring a standard look and feel), run crosschecks, enforce documentation standards, perform context-specific searches, visualize dependencies, trace relationships, access information via an API and much more.

Beware of Scripting

I recently read an IEEE Computer Society article "In Praise of Scripting". Having been a big Perl fan who ran into big problems with a not even sooo big Perl project I have a comment or two on the article.

In the article (and elsewhere) scripting is displayed as the method of choice for free, creative spirits who develop the groundbreaking, innovative (web!) software of tomorrow while the use of compilers with strict typing is the tool of narrow-minded syntax-nazis who develop unremarkable applications by committee.

I beg to differ, having used Perl heavily for about seven years between 1993 and 2000. Perl does an incredible job when a single programmer has to interpret text files and transform data. This is the kind of job I still often use it for today.

But scripting languages like Perl can be a big problem when a team has to create a really large application with complex data structures and elaborate functionality. During the dot com boom a lot of very successful software was written in Perl. What people might not realize is that maintaining and extending these applications was a nightmare, and I know people who quit their job because they could not get away from having to install and maintain these contraptions.

Perl is excellent for many things including shooting your own foot. Neat features can produce obscure errors that are very hard to find. In example, variables don't need to be declared, and have no type. Of cause it is nice that a variable just springs into existence when you need it (less typing, in example). Or that you don't have to care about conversions from strings to numbers and the other way round. Or that complex data structures can be created, extended, and modified on the fly because associative arrays give you all that.

On the other hand, what if you misspelled a variable name? Or the second parameter of a function was supposed to be the forename of a customer, not the year of his birth? Your program will produce odd results but no error. And you then painfully realize, too, that there is no IDE such as Eclipse to help you track down the mistake you made. The compiler won't help you either, because a = b + c is fine for it whether b and c are strings, numbers, or a combination of the two.

Some find it nice that Perl allows you to program in a number of different styles. You can make the code look like C or Java, or more like Visual Basic. There are a number of constructs that don't exist in other languages that allow you to express yourself even more concise, such as "...unless".

But since these constructs do not exist in other languages, people not familiar with Perl have a hard time understanding what is going on intuitively, and some constructs are just not very intuitive ("do this, this, and this - unless something is so and so" - you first follow that "this and that" will be done, but - surprise! - not under the following condition). Different styles, non-intuitive and surprising developments are great in a book or movie, but not in source code.

This article obviously is not exhausting the subject; I'll give it a shot another time.

Software Industry != Software-Industrialization

In my opinion somebody has been seriously confusing the production of material goods with the development of software.

Let's look at the example of Lego bricks. A lot of effort goes into setting up injection molding machines and a distribution network. Once the complex machinery is in place you produce millions of identical items by employing the same steps over and over, with very little human intervention.

This is not how software is being produced. The multiplication and distribution is the smallest problem. In the case of software created for a specific project and purpose the product might be installed only once. Pretty much all of the effort goes into the specification, design, and development of a single unique product.

Where is the industrialization in that? What is industrialization, anyways? Making a single item is expensive. Constructing a machine for creating a single item is even more expensive. But using that machine to make a lot of items reduces the cost per item enormously.

So what that is software industrialization then? The best analogy I can think is the use of tools like IDEs, debuggers, or maybe even MDA. And using standardized methods, tools, and processes. But the advantages of applying all this only go so far; creating software is done mostly by working with the head, not with tools.

This means that developing software is not an industrial process performed in an automated factory, but rather tool-assisted handcrafting in a manufacture, gladly employing sophisticated methods. This is not a bad thing; better methods and tools will help a lot to improve the quality of software, and to speed up the development process.

Breaking up architecture and development

From practical experience, the emphasis in "breaking up architecture and development" is on "breaking" - it does not work.

A customer I have been working for decided to split software development across two different organizational branches: project management, specification, and architecture on one side and software development and testing on the other. The transition to this organizational structure was made in a "jump into cold water" fashion.

The idea was that the high level and therefore expensive work would be done in Germany and the low level cheap work would be offshored to a "development factory" ("industrialization" was another frequently heard term, but that is another story).

This did not pan out as planned, for a number of obvious and maybe not so obvious reasons:

• Architects in that company often are programmers that are either totally out of touch with current developments, or clearly less than decent programmers, or aren't even programmers at all. IMNSHO an architect must have years of programming experience and must be a really good programmer with clear ideas on what kind of programming style promotes high software quality.
  
• Estimates where done independently by the architecture and the development team. Since both teams had different ideas about how the software would be designed and because these ideas never got synchronized the overall estimate often was the total of planned work for substantially different approaches.
• The architects had no real influence on the programmers. If concepts were not liked the development team simply priced them out of range ("if we do it like this (solution that we don't like), it will cost 30% more"). Project management did not have the necessary insight to call shenanigans or to understand and act on long term consequences.
• When architects and programmers are separate persons a huge amount of information must be transferred in the form of papers, talks, and meetings. It is much more natural and efficient to let the senior developers, possibly with some guidance, develop the architecture, and then let them move on to programming as the project continues.
  
• Developers in India are not just "coders", if that management idea of "low level programmers" would exist. They can and want to do architectural work, too. Intelligent programmers will resist to micro-management on the code level.
  
• The separation felt and worked like contracting development out to an external, untouchable company. Estimates had to be accepted like carved in stone; risk surcharges, profit margins, and baseline costs where added, and there was no direct talk to the programmers. Code reviews weren't even on the agenda.
• And - the whole thing just does not work out financially. The plan was to specify everything down to a pretty low level and then let the cheap "code drones" take over. The problem: You spend 50% of the time or more on expensive experts working out a detailed specification and then try to get your money back by executing the last 50% or less with cheap labor. And then you find that instead of ten programmers you need fourteen plus two group supervisors plus one off-site manager to get the same job done, and your customer is not willing to deal with documents written in English. So much for comparing hourly rates by dividing one through the other and drawing the wrong conclusions.
  

As you might have guessed, the split between architecture and development has been reversed after a year of pain and suffering, and surely a lot of money and enthusiasm lost.

Why Doesn't Management Fight Entropy?

Software development projects pretty much always run longer than estimated, and the quality often is poor. Books about software development point out exactly the same problems over and over again since the 70s, and the books are still as valid as ever. Many people I know wholeheartedly agree the described problems are a common pattern in IT business.

So how come the situation never changes? I had parked this posting for a while when I came across an IEEE article about lying in the IT business ("Lying on Software Projects", IEEE Software November/ December 2008) and found there was an interesting overlap.

Frequency of lying:

• Cost or schedule estimation: 66%
• Status reporting: 65%
• Political maneuvering: 58%
• Hype: 32%
  

Who is lying, and why (Cost/ Status/ Politics/ Hype):

• Management (53%/49%/ 44%/ 31%)
• Project Lead (48%/ 54%/ 34%/ 32%)
• Developer (45%/ 30%/ 19%/ 29%)
  
• Marketing (40%/ 20%/ 26%/ 36%)
  
• Customer (11%/ 12%/ 13%/ 16%)

From these number I get that most often management up from and including the project manager is lying, and most lying involves cost/ schedule and project status. Anybody who knows the IT world from inside who is surprised?

(A) There is always pressure on estimates and schedules to beat the competition and to please management (knowing that the difference between what the customer is willing to pay and what the developers are willing to commit themselves to is income). (B) Later in the project there is pressure to hide cost or schedule overruns, a subject closely linked to status reports.

What has that to do with fighting software entropy? There are three basic screws you may turn to adjust project parameters: scope, cost/ time (the number of people aka "resources" is part of this aspect), and quality.

Scope rarely can be discussed. For sure not at the beginning, because nobody wants to try to win a bid by telling the customer "OK, we can do it, but only if you drop this, this, and that requirement". Later in the project cutting scope still is awkward because you can't do it without discussing it with the customer, or the customer noticing if you skipped the discussion part.

Often there are hard constraints on cost and time at the beginning: You have to (or figure you have to) beat somebody's price, and there is a hard date when the project must be finished. Often enough cost and/ or time slips later in the project, but this is always very visible to management and customer, and nobody likes that.

That all makes quality an easy taget. The problem already starts with the definition and perception of software quality. For some the absence of (noticeable) bugs is pretty much the only criterion for quality. The next person cares about maintenance and extension, and therefore about programming style and architecture. But the absence of that kind of quality is pretty abstract for management, customer, and regrettably for many developers as well.

So what happens? In order to cut cost and development time way too often proper software design is tossed over board first (and I saw that happen while developers where cheering). Enhancing software quality seems to be an extra, some sort of beautification that can be lived without. And it can be left out, but not without very real consequences in the future (which is what this blog is all about).

Lack of awareness. Many project managers don't know all that much about the presence, absence, or effects of architecture and programming style. How many projects do you know where the project lead or somebody appointed for the task regularly checks the source code for software quality? And if you know some projects: were these checks about formatting and naming conventions, or about architecture, coding philosophy, and programming style?

If management is not aware of software quality they can't pursue it, plan for it, educate people on it, foster it, advertise it to their own managers, sell it to the customer. Software quality is worth something, and not everybody has it! Others (competitors?) may claim they do, but ask them what software quality is in their eyes, and educate yourself about what it should be, and what the advantages are.

Low software quality does not poke you in the eye like bugs noticed by a customer. But there are a number of symptoms that are easy to spot even without ever looking at the code:

• It becomes more difficult from release to release to get features implemented (the cost and time per function increases strongly).
• Reasonable features are being rejected by the developers because they know what trouble the implementation would cause.
  
• Developers tell you it makes no sense to take on more developers because they "don't know the internals" (of course we all know that programming does not scale the same way as filling sand bags does, but it should not be impossible to take on new programmers or replace some).
• The cost for even small changes becomes so large that even when all details can be explained it simply doesn't feel right, and it is embarrassing to the tell the customer.
• Programmers strongly avoid or plain refuse doing any work on certain parts of the application (knowing any change to that cesspool of code will break things in an unforeseeable way).
• Programmers are leaving the project in droves.

While this may sound like the developers are responsible, they quite often are not: it can't be expected that sufficient time gets spent on architecture and design when the only goal is "to have something deliverable by date x". On the contrary I have been working on projects were the programmers "ganged up" and "secretly" refactored code, sometimes even on their own time, because they felt they never would be granted the time to change something that turned out to be awkward, an obstacle, or a constant pain in the neck.

Programmers must know about and code according to good programmings standards, and management must allocate the resources for this. This includes selecting and/ or educating programmers with the right skills, and factoring in software quality into estimation, planning, implementation, and marketing.

Conflicting goals. I worked for a company where one unit was responsible for initial software development and another for operations, maintenance, and extension. I know that this is not exactly an exotic situation. The problem was that there was nobody watching the project who was high enough in the hierarchy to oversee both initial development and continued maintenance.

Good architecture costs some extra effort, no doubt about that. Good architecture and the improved software quality that comes with it often doesn't you get that much of an advantage in the first release of a software. The payoff comes later when changes and additions are easier and code is more understandable for new members on the team (just to name a few points).

In our case we just could not get the customer to pay for some additional architectural efforts. They even agreed that it would be better to put in some more effort for a better architecture, but since they would not receive the benefits they simply could not justify the expenditure. Of course there would have been an overall savings, but, no, the decisions were made by two different units with two different goals. And, of course, we got blamed again and again for high development costs when the software was extended during over a dozen releases.

[This article very likely is going to be extended, and/ or broken up in smaller units]

If it is awkward, it is probably wrong

Just a short insight from programming an application for myself. Whenever adding or changing a feature

• feels overly complicated
• doesn't quite fit into what's already there
  
• makes you feel you'd rather do something else

something probably is wrong or suboptimal with the architecture. Why? Because the opposite is so true: when the architecture is right, adding or changing features is a breeze. Just a few turns of the screw, and voila. No open heart surgery and wondering if things ever will work again like before.

As reasons why architecture turns out suboptimal, even if you develop for yourself and call all the shots, I found

• An idea has not really been thought through. Get away from the computer, and "program" with paper and pencil for a while. Do something else for some time, and come back to tackle the problem later.
• Changes crop up in places where they haven't been anticipated and planned for. If an aspect of the program undergoes frequent changes, maybe consider implementing a mechanism accomodating that (a framework, plugins etc.).
  
• The requirements changed so much the original approach just does not fit the problem optimally any more - acknowledge it, and change the architecture.

Just my €0.02.

Is there a job called "coding"?

"Management has announced that project management and application design will be done locally while coding will be done offshore."

This announcement conveyes a number of messages.

The tone implies that coding essentially is some type of basic work. The thinking has been all done; now the results have to be written out in full and typed into a terminal, just like entering data from a fax or letter. Unless application design is done to a very fine level of detail, writing source code requires a lot of intellectual work to convert common language specifications into a running program.

The announcement implies, too, that coding is some kind of low level work. The architect has designed the building. Now the building company takes over, and while the construction of foundation, walls, and roof requires specific skills that an architect might not have it is quite clear there is a difference in the attributed value of work, both intellectually and financially. Writing source code requires very specific knowledge of ever changing APIs and frameworks. Apart from that, software architecture and implementation never are as independent as planning and building a house. While the latter is a pretty tried and true standard affair the former means solving a new problem with new means almost every time.

Since the company employs business engineers that capture requirements and produce a specification, architects that design the internal structure, and developers that write the software, "coding" must be what developers do, and coding is going abroad. Not too happy a perspective for "coders", whose value has been downgraded while being informed they will be made redundant. The offshore "coders" probably don't see themselves as data entry personnel, either. In example, I found Indian programmers at least as capable (and ambitioned) as their local counterparts.

The offshoring of "coding" work encourages management to relabel developers as architects, which might be what they are - or not. Often, the following questions are never answered: What does an architect typically do? What qualification must an architect have? Does the company provide formal training, or are architects simply being appointed? This non-definition of what an architect is leads to the employment of architects who never have been doing any serious programming, which in my professional opinion is a sine qua non prerequisite.

Management does not quite understand what their software developers do when they talk about about "architecture" ("planning the system down to the details") and "coding" ("typing in source code"), especially in the context of offshoring. Of course development work can be split up like that. But then architecture would comprise 80% of the effort, and not much could be saved by getting 20% of the work done at low cost. Additionally, problems and insights during implementation often prompt an adaptation or change of architecture, requiring a more iterative approach than the waterfall modell "design here, code overseas" provides.

Going offshore - Things to keep in mind

One of my clients decided to offshore development work. The idea is that high level, well paid work - maintaining direct contact with the customer, capturing requirements, specifying and designing the application - gets done locally while the coding gets done offshore for cheap.

This didn't quite work out as planned, for reasons that were not too difficult to anticipate. The scenario described above touches on a number of issues that I would like to address in a series of blogs.

The anticipated subjects:

• "High level work" - What separates high level from low level work? Why is high level (= high cost) work not offshored as well?
  
• Separation of architecture and development - Does this provide benefits? Improve quality?
  
• Going offshore to reduce development cost - How much cheaper is offshore labor really? What additonal costs are incurred?
  
• "Coding" - Is there a job called "coding"? What does it consist off? What happens to the onshore "coders"?
  
• Ethical aspects - What are the implications of producing offshore in low wage areas of the world and selling the product in high price markets? What does it mean to the current workforce?
• Prerequisites - What kind of projects are suitable for offshoring? What processes should be in place before going offshore is attempted?
  
• Economical aspects - Are there other, better ways to reduce development cost? What does "better" mean in this context?

What does that have to do with Software Entropy? Software quality gets influenced by many factors, and the longer I work in the field the more I recognize that most problems in software development aren't technical. Management decisions have a huge impact, and going offshore is one of them.

Software Entropy

This is a blog about the decay of software - and how to prevent it. Wikipedia has a detailed explanation of entropy. In short, in can be summarized as

• Entropy is a measurement of the degree of disorder in a system. Higher entropy means less order.
• When two systems of different entropy adjust to each other, the total amount of entropy increases.
  

What does that have to do with software? There are some striking similarities:

1. The decay of software is an inherent process. Requirements change during implementation, features get added that don't quite fit the original architecture, "quick and dirty" fixes are introduced, and people are following different coding philosophies.
   
2. If left alone things will get worse. It requires energy in the form of reviews, redesign, and refactoring to fight the decay.
   
3. If the environment does not provide rules and guidance, the software will adapt to this low standard.
   

The next question: if it requires effort (money, time, resources) to fight entropy, why should you pursue this goal? If you are or have been programming you already know the answer. If not: you gain software quality in the sense that code becomes more robust, readable, maintainable, extensible, flexible, reliable, and - gasp - more enjoyable.

Keep in mind the initial implementation of software is just one of many cost factors. The operation of unstable systems, fixing bugs during production, difficult addition of features to the software adds substantially to the total cost of a system over its lifetime.

This is why fighting software entropy is important.