Process Over Technology

As the struggles continue with the application rewrite I'm currently involved with, I've read and reread these articles by Joel Spolsky, James Shore, and Chad Fowler on why this path generally leads to failure. After I finish reading articles like these I often ask myself: since many of the industry thought leaders think these projects are a bad idea, why are they still so common? I mean, Joel's article was written in 2000. Eight years later (an eternity in technology) that article is still extremely relevant, but it's lesson has failed to penetrate mainstream thought.

There's not enough industry focus on how best to approach legacy system enhancements. Many software development articles that garner the most attention focus on quality improvements delivered through innovations in technology - new programming languages, frameworks, APIs, architectures, and hardware. While that stuff's definitely important, they're relatively little help to application developers looking to extend the life of existing systems.

Martin Fowler's Refactoring book is the best example I've read for extending the life of existing software. This book - and articles like those in the opening paragraph - are timeless because they describe thought patterns for maintaining applications. Their lessons are applicable regardless of any specific technology or language.

In a recent StackOverflow podcast Joel Spolsky and Jeff Atwood discuss a recommended reading list for developers (Jeff had a previous post on the subject). In looking through their lists, I'm not seeing any "Teach Yourself Perl in 8 Hours" or "Ruby for Dummies". Specific technology is not the focus here. These recommendations teach software professionals how to think - improving quality, efficiently, and allowing them to deliver greater value.

I'm starting to believe that there are an increasing number of developers who are starting to think more like this (or at least I'm meeting more of them) - focused on improving processes rather than relying on technology innovations for increased software quality. I hope this mindset spreads to more of the development teams I'm working with.... before the next big rewrite. This thing is painful.

*****

Jeff Atwood also had a recent post on Dealing With Bad Apples. He has a similar take to my Observations in Poor Management.

Comments

Dharmesh said…
Exceptionally thoughtful article.

I think the reason we don't see more focus on the "get more out of what you have" is related to "agency syndrome".

Extracting more out of legacy systems is not "fun" and in a pure economic sense, is not valuable (for the individuals making the decisions). If I didn't own the company (or have a significant stake), it'd be hard to invest the energy into getting more out of legacy systems. That's why so few people do it.
July 21, 2008 at 7:16 PM
Post a Comment

Popular posts from this blog

I Believe...

A recent reorg at my company left me with a new manager - and a different approach to software development than my team had been previously following.  Our new approach is one that I don’t necessarily agree with, but it led me to think about - and reevaluate -  those tenets of software development that I think are important and that I believe lead to increased quality and productivity. This post will consist of fairly high level discussions about how to organize code, teams, and projects - but contain very little actual code. Many of these ideas will not be my own.  They are mostly ideas I’ve learned from others and their willingness to share their experiences with me.  They are, however, ideas that I’ve practiced and hardened as I’ve worked to build my own ideal environment for delivering value through software . Many of these ideas I now take for granted as commonplace (even though they aren’t).  I felt a need to document them anyway - so people can understand what to expect (a
Read more

Performance Tuning JCAPS - Part 2

It's been close to 2 months since my first Performance Tuning JCAPS post. Since then, we've noticed our servers running out of TCP connections under heavy load. Researching this problem, we learned that the JCAPS' JMS server makes heavy use of TCP in implementing Request/Reply queues . We approached Sun for guidance and they assured us that they've had success implementing high throughput applications using the JMS request reply solution... but how? It appears a multi-step solution is needed. First, running out of TCP connections in a scenario like ours is a JCAPS bug addressed in an ESR (110348) and rolled into JCAPS 5.1.3 Update Release 3 . We installed this update and noticed a marked improvement. Running my simple 75 user simulated test, transactions took 2521 ms to round trip (compared to the previous time of 20128ms). While this is great improvement, an average of 2.5 seconds is still really slow for this simple transaction. We reported our findings to Su
Read more

FRail :include

I really like developing with Rails, but I've been frustrated the last few days by some things Rails should do quite easily, yet doesn't. I've already written here and here about some of my struggles with Rails :include clause. Here's one more... Let's say you have a has-and-belongs-to-many relationship. If you :include this relationship in a find query, Rails will automatically create the join clause including the lookup table! That's cool. Unfortunately, it looks as if only the :include clause provides this piece of functionality. Why isn't the same functionality provided via the :join clause or through a general purpose module? This doesn't make any sense to me! I'm working on a database application where I don't need to display a lot of data, but the data displayed is heavily filtered by it's connections to other information in the database. I need to join a lot of tables to perform the filtering operation and using :include
Read more