Adventures in Geekland

What colour is your code?

Thanks to Jeremy Ruston for this - it started as a drunken conversation about 4 years ago, developed through a couple of years of casual use in a professional environment, and now I use it for a variety of reasons:

* Explaining why product companies are bad for business users with specific requirements
* Understanding emotional commitment to technology within IT departments
* Structuring code-base dependencies

Consider an [arbitrary] piece of code. It's indoors, it's well behaved, and you can be proud of it. What is it about that code that you like? Is it elegant? Is it clever? Does it enable something? How would you measure the value of code?

Well, one of my thought experiments runs like this: I'm going to give the code a colour. The colours I can choose from go like this:

• Yellow - only a specific business customer needs this code
• Pink - only a particular market (e.g. group of customers) would use this code
• Black & White - this bit of code is valuable to a whole bunch of markets
• Blue - this code is a piece of infrastructure that I cannot change.

What's that? Not clear enough? Let's try an example....

Yellow:

• a configuration file in which I store the email address of the system administrator
• a custom rule that defines specific discounts for a favoured partner
• a complex sql query that generates a report for that one customer who has 70 call centre staff
• that natty bit of boolean logic that decodes the snazzy protocol for controlling the new swiss-made robot that just arrived in your warehouse
• A customer logo

Pink:

• A model of products and pricing schemes that supports pricing by weight
• An integration with a supplier's order management system
• Decoding rules for retail bar-codes
• The URL for the equifax credit scoring service

Black&White:

• Huffman encoding algorithms
• A virtual machine for testing electronic circuits
• Default velocity configuration file

Blue:

• The J2EE specification
• That mainframe messaging format
• Oracle JDBC drivers

The model of code costs (pre-test driven) works out as thus: Some code valuable, and some is worthless:

Yellow code has no value - in fact it only really has a cost. As a product company, I want anything a specific customer requires to be cheap to create.

Pink code has some value - if I can open up multiple customers, offer them something common, I might start making a profit.

Black & White code - I have something that is truly unique, gives my company an edge, and that might enable me to sell my company - or to buy another company. I'm thinking mergers and acquisitions.

Blue code - It's something I'm lumbered with - it has no real value in itself, except as an underpinning to other things. I might generate a large amount of value from using J2EE EJBs, or I might not. But I probably have to use JDBC to enable any value...

Note that colour coding has nothing to do with complexity. It is all about return on investment.

Cost on the other had has everything to do with complexity. If my team of 50 propeller-heads spend 10 years developing something, I damn well expect it to be Black & White. If they come out with something that only suits one of my customers, well - I'm going to have to give up my plan of early retirement in the Seychelles.

Conversely, something that is easy to create has no real value to my M&A agenda: good for you you've written a routine that will count the number of characters in a string! Come back when you deliver ME some value.

As a product company:

At the intersection of high cost and high value, a rational product company will create as much black & white code as possible. In a quid pro quo, a rational company will make adaptability of their application extremely "cheap" (in other words: configuration and scripts!) and hand it over to the customer, or start a services company.

The flawed model here is that, from the customer's point of view, a vendor's application is mostly Blue. And the skills required to customise even a simple product are high. It is unlikely that a vendor's application will provide a competitive advantage (unless they are the only purchaser). From the product company's point of view, they have no interest in making customer specific alterations. A trap, for the unwary.

Emotional attachment

A similar pattern happens in IT departments of medium sized organisations. The intellectual property of the IT department - the crown jewels, if you will - is usually some fiendishly complicated system that is difficult to change. Black & White. Since it encapsulates all that the business has done so far (for who can predict the future?), there is an immense amount of pride in the system. Rightly so.

From the business side of an organisation, what has been done, is just a cost. They aren't going to sell their company on the back of some wonderful system for expressing business logic. They just want to express new business logic. Their "Black & White" is new business rules and new models of business. Brands and Market penetration techniques. The best Black & White of all is a large, growing, customer base. What is Black & White to IT becomes Blue to a business. Yellow and pink (business) code is often infeasibly expensive.

UIs are often the primary mechanism by which customers judge a business. When they become locked down by the IT department - making new channels difficult to create - there is tension.

As an aside, it is for this reason that I believe that multiple-user interfaces are required on many IT projects. If usability analysis and interface design is a scarce resouce, channel creation will be deemed Yellow by IT, and therefore under-invested.

Dependency analysis

When refactoring code, it is almost always a process from Yellow through Pink to Black & White. Agile developers don't short-cut this route. They also try and keep things simple, leaving the costs of change quite low.

However, this mutation leads to the following property: Yellow code depends upon Pink code. Pink code depends upon Black & White code. Ask yourself - where does the "utils" package go in a project. It is Yellow, Pink or Black & White? If it's more than one, split it up.

An example? If you have a UI which is designed solely for admin users, it is Yellow. The complex services that this admin UI uses will probably also be yellow, but there may also be some pink and black & white elements (for instance, that generic user manager is black & white, but each user's vehicle registration number is probably pink). The (branded) UI that customers use is pink, but the logo itself is yellow.

If you see a yellow piece of code used in a pink piece of code, flag it up. Use colours as part of your vocabulary.

posted by Nick Drew @ 9:20 am