Hugh pitched at idea for English Cut to limit their production to 100 suits a year. Apparently they’re now going ahead with it. As Hugh explains, this approach really brings focus to their team as it’s clear they have to nail the quality and service part as they can’t rely on increased volume or new business to make money. I love that type of clear focus and it gets me thinking how we can apply it at ClearSpace. How would that even work in custom software development where you have multiple clients running multiple projects?

Bug tracking software for only $5, even Scoble linked to it. I admit I didn’t read the fine print, but it got me thinking, initial licensing costs for a bug tracking product would be the least of my concerns. Support, maintenance and upgrades are what I’d look at. The reality is it’s ugly and costly to migrate your data out of a bug tracker into a new product. So once the average customer is in, they’re in for the long haul.

Example, the Fogcreek boys charge a flat $2995 US rate to migrate your data out of your old bug tracker into Fogbugz. I’ve done that work for a client and that’s a reasonable rate and by no means outrageous.

A not-so-nice company could base their business on this type of lock-in model. Discount, or give away, the software, get clients in, get their data and then make it painful to leave. Create borders to exiting your product. (Note, I am by no means claiming this is the case with the above product.)

Most software companies don’t necessarily do this on purpose but don’t fool yourself into thinking some don’t. When I was with MKS, we spent a lot of time and resources moving new customers off old source control and issue tracking products onto ours. I was directly involved in building tools to make this process easier for our services team as it lowered barriers to entry for our products.

I went so far as to suggest several times to product management that we build tools to do the opposite, ie get our clients off our products. We had the tools to go one-way, it would actually be fairly simple to have them go the other way as well. We could then offer this up during the sales process. We will help you painlessly get off our products if you want to. We do not base our business on lock-in and only want you using our product if it’s serving you effectively.

Ah, needless to say product management never quite latched onto that idea.

People who’ve never programmed or written large amounts of code will sometimes mistakenly, apres a few pints, ask me about it. One thing pints will do is guarantee you a long answer from me. The one aspect I often describe that tends to surprise non-techies is the art and authorship aspect of writing code.

Fictional friend says…”I just thought code was code, I didn’t quite realize there was an art to it.”

Ultimately, writing code is no different than traditional writing where the result’s are novels, articles, etc. A hundred different authors will write about a topic in a hundred different and unique ways. Most will be painful to read and downright ugly but will achieve the task of conveying the details of the topic. You can achieve success in the result of conveying a topic without people actually enjoying the act of reading it.

Writing code is no different. A hundred different developers may all achieve the end result the code is meant to achieve, however, a minority will do it in a graceful, well crafted way. Generally speaking, no one wants to read other people’s code but if you have to it’s a rare pleasure to read good code.

Years back, I took a 3 day course on Design Patterns. I’ve never been successful in acquiring knowledge in the classroom format, however, the course did provide a thorough introduction to the idea of design patterns as applied to software development.

It’s always irked me how little props are given by software folks to the originator of the idea of patterns, that being Christopher Alexander. While the concept of reusing patterns of problem solving have been around longer than dirt, it was Alexander who formalized them with his books The Timeless Way of Building, A Pattern Language, and The Oregon Experiment. I believe the rest of the history consists of Kent Beck and Ward Cunningham playing with the application of these ideas to software design back in 1987, presenting their results at OOPSLA that year.

Some pattern related links…
Design Patterns Java Companion
Patterns and Software: Essential Concepts and Terminology
Pattern Depot
Chapter 1 from the book – Pattern Hatching
JavaWorld Java Design Patterns
Design Patterns in Java Reference and Example Site

Another good link courtesy of Joel. The article is about a software developer attending a course on lean construction management since the so-called ‘old trades’ have it all figured out.

“What are you doing here?” they asked.

They were construction foremen, superintendents and project managers attending a course in construction planning from the Lean Construction Institute (LCI). Indeed, what was I doing there?

I started to explain: “In software development, we are told we should manage our projects like construction projects, where a building is designed at the start, cost and schedule are predictable, and customers get what they expect.

”Silence. “You’re kidding, right?” “No, honest, that’s what we’re told.””In my construction class, the idea of “freeze the design” meets the same fate as “follow the master schedule.” Laughter. Not only is freezing the design impossible, but given the long building times in construction, attempting to do so is sure to make the real customer – the people who move into the building – unhappy with the result.”

During the look-ahead period, incomplete designs are identified and arrangements are made to fill in the blanks. In the same way that lack of materials is the biggest cause of construction delay, lack of requirements is the biggest cause of design delay. The ‘Last Planner’ system pulls in requirements just as it pulls in materials, and LCI recognizes that designs done as late as possible are often the best. In fact, they recommend that design decisions be made at the ‘Last Responsible Moment’ even as materials arrive ‘Just in Time’.

The above quote reminds me of most traditional software processes and their attempts to delude people into thinking that certain elements are frozen. There are stages such as code-freeze, featured-freeze, etc. While these processes are certainly well thought out and battle-hardened they are also troubling in the possibilities they ignore. The reality that we prove to ourselves time and time again is that code, requirements, features, etc are never frozen.

Why is this a problem? Let’s look at requirements since the issue is similar on all fronts. Developers are often asked to adhere to requirements that no longer make sense. The process of implementation continually clears an initially muddied picture. We learn a ton through the act of writing the actual code.

The concept of freezing requirements places a developer in a difficult spot. They have to either admit that the requirements they wrote were ‘wrong’ and correct them given current information and understanding, or stand their ground and argue that their original requirements were sound. The latter most likely involving deluding themselves or ignoring the reality of this new context. To be clear, what I’m talking about here are requirements that were valid when they were written and have been invalidated over time. Invalid requirements are still invalid requirements and I’m not talking about a process of correcting poorly crafted work.

Forcing developers to admit that their requirements were incorrect in this style of environment is toxic to that individual. As a programmer, not being able to write valid requirements means you may not be capable of designing software, which means you’re nothing more than a code jockey. This makes little sense. The original requirements were valid in the context they were written. That context has changed so it’s reasonable to assess whether the requirements should change.

The reality is that requirements are never frozen. Should we willy-nilly change requirements day in and day out? Obviously not or we won’t finish anything. If, however, we embrace this reality and drag it out of the developer’s closet then we can look to leveraging it to improve our work. Construction’s adoption of the idea that “design decisions be made at the ‘Last Responsible Moment’” is a good example of facing these types of realities.

The alternative is having a developer spend their valuable time and energy forcing the square peg of an out of date requirement into the round hole of an implementation phase. This wasted energy cannot be underestimated. You now have a developer using their creative energies to write code to invalid requirements.

None of this line of thought negates the need to craft the most accurate requirements possible at any point in the design, including the beginning. What’s being suggested here is that we should strive to make developers comfortable with the fact that the requirements they write can become invalid during the implementation process. That’s a reality we wish to deal with straight on, and it is in no way a failure on their part. This last part is the key. Developer’s must understand that a requirement that changes, or becomes invalid during the implementation process, is not a bad thing or a failing. Address the changes, learn from them and move on.