Amish Software

Last week, I spoke about ‘Resuscitating the dread word ‘Agile’ ‘. The core of that post was that Business does ‘Agile’ wrong. Business misunderstands what it is buying when it pursues the ‘Agile’ practices. Business thinks it is buying a software product. But what agile provides is usually strategic information about customer desires. These ideas continued to boil in my brain when another thought hit me. The software Industry is still very young. We’ve only been making software since we had computers. By contrast, we’ve been making furniture much, much longer. Like since we’ve had agriculture… As a result, we haven’t had time to discover suitable manufacturing patterns. That being said, many businesses are seeking these patterns from other industries, for example furniture or automobile manufacturing. Software Businesses have been searching for ways to apply the old practices in an effort to get a handle on this new beast. From what I’ve seen, read, or heard, there are a handful of predominant patterns. Today I want to talk about two archetypes that I have experienced. The first pattern follows my previous post. It is the Business ‘Agile’ way of development. We get short, controlled, well-measured, impotent steps. We know when we’ll finish, because we can measure the man-hours it will take to produce the rest of the pieces. Like knowing how many steps are left in the process on a factory line. Each man has a task he must do on the item, and then he hands it off to another person. Sure someone might be working on a wheel, and another on the engine. But he needs to finish polishing the mirror. Then later they can put all those things together and out rolls a new Model T. For those who have experienced this style of work, it can be draining or down-right degrading to your spirit. You become the cog in a machine that produces standard measurable quality. There is little for you to be proud of, nor any part of the work that could be held aloft as the epitome of excellence. To put it bluntly, these practiced vulgarize the creative work of software engineers. It encourages management to think of the developer as expendable and replaceable. Note, I am not arguing for indispensability of the engineer. Instead I would argue for recognition of individual value and contribution. In contrast, I have worked for a shop where developers behave more like craftsmen. The best allusion that comes to mind is a weathered carpenter sanding a table, or assembling a barn with time-tested methods. He rests easy knows that his creation will stand for generations. To be completely honest, I think of the Amish Barns I’ve seen up north. Specifically their construction techniques that required no nails. The developers at this shop naturally wore many hats, from testing to deployment. But when you spoke to them, you could tell they were pleased with their work. Discussions were lively, and issues were rather easy to resolve, even across larger systems. As you can guess, this shop was much smaller in scale. It was also lead up by two seasoned Software Engineers. So, the two styles are Factory-line, or Craftsmen. Speaking from experience, I by far prefer the craftsmen shop. The culture of the office was freer, but maintained a strong discipline. Not only that, the output of the office was a higher quality too. That is not to say that high-quality code did not emerge from the Factory-line. Merely that producing such quality was more difficult and less common in the factory-line shop. With these two types in mind, I realized that the differenced weren’t merely in style of management, but ran much deeper. The first difference I found was in the language that each shop favored. The Craftsmen shop favored a recent edition of C++. The Factory-line shop favored C# for new development. The language differences were just the surface, but they are a good touch-point for the pattern of differences. One shop favored older, well-worn and stable libraries. The other favored newer, less stable and generally more finicky libraries. And when I realized that, I saw that the problem was also with us, the software developers. Perhaps it is a reaction to Business ‘Agile’, or perhaps its just a part of the culture. We scrambled for the ‘new technology’ that will ‘solve all the old problems better, faster, easier’. Of course, after a time, experience teaches that this can never be the case. But on the whole, the software development community leans towards neophilia. With the rapid change in our tools, it appears we may also be drifting towards less proficiency with these tools. And that is when it hit me. It’s not only business that does agile wrong. We do it too. In fact, we might even be pursuing software development the wrong way. In the rush to find the new, to get the business people off our back, we haven’t had time to look around for another option. At least, those of us who work for business majors haven’t. Perhaps companies founded by software developers can still get it. Or maybe it’s a size thing. So as I see it we’ve two predominant patterns. First, we have the factory, with its pre-cut particle board. And its pieces precariously held together with glue and the prayers of the innocent. AS one alternative, we’ve the Amish carpenter, crafting his table, or drawers. Using well known and well-worn tools handed down to him by his father. The factory furniture might be ready sooner. It might be cheaper too. But the table so finely crafted, will stand the test of time. Such quality comes at a cost. The question before us is: Is quality worth the cost? The question isn’t just about price. It is also about practice. What are we willing to give up to gain quality? Are we willing to work with older, more stable technology? I know that when I started in the work-force, I would usually sneer job postings that listed ancient or arcane languages on them. I am beginning to reconsider my stance. What do we want to be? Factory cogs, or Amish carpenters? Or perhaps is there another way?