Contemplating success

Getting out of the never-ending mad dash that ruled my life for much of last year is starting to give me time to think about and hopefully learn from the events from that time.

Lately this thinking has revolved around how to do technology right, and how technology should be treated by business.  There's always lip service about what technology should be to a business, and how the engagements should work, and so forth.  But I think we so often find ourselves working from a flawed understanding of what success is to the business that is initiating the project.

A common position I end up in is taking over what pretty much anyone would call a failed project - a project where a lot of money has been spent and the resultant product is not even of sufficient quality to expose to others, let alone started to make money.  Aspects of the project that have already been paid for have been found not to be of sufficient quality (or even delivered at all), and need to have more money spent on them.

But I hack on the existing project for a few months to get it to the point where I wouldn't put a bag over my head to avoid being associated with it.  The project launches, and after a few rough patches and late nights, I get the last major kinks out, and the project starts making money.  Some might even call it a "success".

But is it?  If I'd been on the project from the beginning, my arrogance forces me to insist that the project would have been delivered properly the first time, with less back and forth to QA, with fewer publically-visible problems post-launch, and thus would be cheaper in terms of direct costs and indirect costs to regain the confidence lost during this whole process.  So, while the second part of the project (which some may call another project entirely) in itself is successful, the entire process of developing the technology was more expensive than it needed to be.

And that's not even the most damning difference.  If I'd been on the project from the beginning, my arrogance forces me to believe that the end result would be better in the way that most matters about technology in the long run - how it facilitates or hinders changes in future.  Or, put simply, a solution I'm involved in would give the company agility.

Many companies have a great idea, and get to market by the skin of the teeth of the people they could find and afford to do their initial technology.  And, because of the way the technology was rushed and was cobbled together, changing it is often scarily hard.  Which isn't a problem at first (when they have the existing developers who remember all the ins and outs of the system), and so the company's great idea and timing and efforts make them profitable and renowned.  Fast forward a few years, and they're cursing their main source of income and often the thing they're most famous for (if you're talking a web site, for example).

Why?

The developers are usually gone by now.  Even if they aren't, they no longer have the ability to keep in their heads all the hacks they've been forced to put in to the original system to keep it ticking over "until we rebuild it all".  There's entire pages of code dedicated to special cases for particular user names, groups, and so forth.  When changes do happen, all effort is put into reducing the intrusion on the original system, because the company has been bitten by the hard-to-detect consequences of previous changes.

Success or failure?

At the beginning, a great idea was all that was needed to get into the market, and delivery could be made timeously.  Now, there are more people available, and there's more money available.  Sounds good...  But, despite the additional people and money, even small ideas and small changes take a long time to make, and the next great idea is near impossible to implement.  These are the small and big ideas and changes necessary to continue being relevant - to not become an also-ran of the very area they once owned.

Unless your business usage of the technology is once-off - a gimmick web site that has a specified shelf life - then you have got to think about the cost of change built into that technology.  (By the way, this is also why open source and/or open standards are such a no-brainer in the long term - you never end up having your data and processes tied up in some proprietary system that makes the cost of change too high when you need to change something about your business.)

I don't claim to have the answer to how one can define success, but this is the simplest way to describe what I'm feeling now:

Success can't be measured only by what you have achieved - the resources, the accolades, and the good will.  More important than those, it should be measured also by what you can achieve from this point on.

(This also applies to any development project independently of the business that initiates it.  Taking the laziness as a virtue approach, you can measure your success by how much effort you save yourself by building something that's easy to maintain and extend in future.)