10 Dec 2007
Saw another interesting post over on DZone aptly titled Changes Are Expensive, Damn Expensive.
Now I agree more or less with the premise of the argument. There will always be a cost associated with writing or releasing code, invariably this cost will rise as the product matures in the market and develops a sizable customer base. Not only do market demands or shifts dictate the cost of a change (or conversely it’s earning potential) but the organization itself plays a significant role in determining the true cost of a change.
The developer in me doesn’t necessary agree with the notion that code re-use should significant increase the cost of a change. We’ve all been beat over the head with the low coupling – high cohesion hammer enough to hopefully understand when and how code should be re-used.
In my mind, it’s all about timing and more importantly becoming pro-active individuals. The later ties into the act of balancing both the strategic and tactical objectives of an organization. Having been through the high growth periods of a startup, I’ve come to realize the importance of establishing strategic goals (we didn’t exactly have them and played catch-up long after the fact). In times of pressure it’s very easy to forget the future and plan only for the present.
A lot of software companies have realized this, and they provide a test suite along with the code that they handover to their customers.
I’m not quite sure what kind of software the author writes (I realize he’s in India so perhaps it’s outsourced work) but short of open-source projects I’ve rarely ever seen code let alone a test suite delivered to an end-user. An interesting idea but difficult I imagine to do in practice with a diverse set of customers and demands. As a user of software, it’s been long evident that writing test cases doesn’t guarantee quality software nor ease of maintenance. It shows a bit of added diligence and with the right team could take you a significant ways towards building maintainable software but *unfortunately *it’s not a guarantee of anything.
The act of making a change impacts far more organizational groups then development, certainly if it’s any way shape or form user-facing. Not to be left out would be the customer support, quality assurance and end-user documentation costs associated with any significant change in functionality.
Changes are inevitable and when adequately balanced an important aspect of growth. Probably the worst thing a developing (or already established) organization can do is attempt to ignore them. Fortunately for us we’ve be witness to an emergence of organizational processes (some development-focused, some not) that should allow us to more easily embrace the notion of change.
04 Dec 2007
A colleague pointed out an interesting article over on InfoQ aptly titled Is Quality Negotiable.
Obviously if you’ve ever written a line of code or used a piece of software this question has been implicitly or explicitly answered for you.
It’s fundamentally important that both individuals and organizational groups have a clear understanding of what quality means to them. There’s no doubt in my mind that quality means very different things to different people but taken together that’s part of achieving a successful balance. Debate is healthy and it’s important that you stay true to your core beliefs, be they writing unit tests or ensuring each release has suitable user documentation. You can’t satisfy everyone but by talking through a problem or having concerns answered, a clear set of priorities and direction will be established.
As a developer, I believe quality is negotiable, it simply has to be. Much to the same degree as a feature should be negotiable. My personal philosophy on development would always be to release less features of a higher perceived quality then more features of slightly lesser quality (the old 100% of 80 or 80% of 100 problem) but I’ve come to understand that there’s a time and place for both. Deadlines are a reality but there’s a balance that must be struck between tactical and strategic thinking.
Focus too much on the tactical aspects of development and release planning and chances are you’ll be left with a pile of technical debt and a team of unhappy people jumping from project to project. If you’re really good, there’s a good chance that you’ll have a few satisfied customers. The early days of a start-up are often very tactical in nature, they have to be, but it takes a heroic effort across the board and is very difficult to maintainable in the long run. Tactical thinking is a reality and it’s important to make people aware of the costs associated with making short-term decisions.
Focus too much on strategic thinking and you’ll be hard pressed to ever build a realistic release plan let alone get features into customers hands that actually perform how they expect them to. Truth be told, you’ll still accumulate technical debt. Don’t get me wrong, I value strategic thinking and it’s a big part of what I do on a regular basis, but it should be relatable back to reality.
There’s an important balance to be struck and it goes beyond the code, the cost of doing business, or even the customer. It’s been said many times before but quality is not magic nor is it something that can tacked on at the end of a project. Further to that, the waterfalls froze a long time ago and it’s equally important in todays environments to remain flexible and open to change. Quality should be considered a characteristic of the process that went into creating the product and the act of managing that process is difficult at the best of times.
19 Nov 2007
In case you missed it Interface21, the company behind the popular Spring Framework, has re-branded itself and will henceforth be known as SpringSource.
Same folks with a slightly less mysterious name.