Deliverables

Deliverables, what it is really? I've seen so much horrific code delivered by "senior developers", I could almost cry. Is it really their fault? Is it because they are not familiar with the current industry which they are trying to develop some functionality a specific customer wants? Or it is the customer's fault for not being specific enough? Is it the platform they are developing for is inadequate? Is the time frame too short to actually deliver something which is just a bit better, or even great? Or they are just not good enough?

One particular thing is that if you have consultants making the deliverable they, too often, develop like they did on their last assignment. Or like a jack-of-all-trades developing a back end service like it was some front end webpage. The customer, is happy since the application works, but the code is bad. Should I care as long as it works?

I watched a video with Java Champion and rock star Adam Bien where he says "I don't understand why architects always insist of putting things in different projects." Well for a small projects it might not be necessary but for large projects this is absolutely fundamental because there are so many people are working on the same codebase. The code starts deteriorating into the infamous ball of mud. And it really doesn't need to that large before the effects of the ball of mud starts showing. Even the tests starts deteriorating into testing that the method invokes (Unit tests are a different topic, and some of you might scream "code coverage"). Also when starting out you have to layout the fundamentals for maintaining your code since you won't have the time to fix it later.

One thing in common of these deliverables you inevitably write stuff for deliverance, keeping release dates, not maintainability. If you are developing a shoot-and-forget project (you don't need to pick it up and maintain it) I guess that's a feasible way of doing things. Although if you are ending up maintaining it and expanding it you have to be really careful with deliverables or you'll end up rewriting it.

Most companies ends up in this situation. It starts out with a rather major refactoring of the current system to adapt to new expectations or business needs and it starts to ripple through the whole system, and soon you are in a black hole you can't see the end of costing a magnitude of money and time. I've just seen a such thing where the project is coming to an end, but the functionality is just halfway and has to be "maintained" to finish, if ever. And that's one of the problems, system never gets finished but somehow we always act like this is the case.

I believe the agile manifesto is utterly rubbish, however a great idea. I do believe in incremental development, however it requires a huge amount of knowledge to do it, and in the real world you are not getting people which fully understand the whole complex reality of the systems interacting. The problem is really: When solving the problem at hand, whose problem are you solving? Are you solving your programmatic problem, the system's or customer's problem. Also if you are doing a change to a system, how much work should be done to satisfy, not just the "business value" but also the system? With the change you have just done are the code needed of refactoring? Will you do it or will someone else do it? Most of the times no one will do it because there's no time or money to do it. Most of the times it ends up building a intersection without any connecting roads. The intersection works but what about the rest? The most important thing, as I wrote in my earlier post, your company is as flexible to change as your system is and you'll probably end up with the refactoring anyway.

Business value is a misused term, since your systems are your heart of your company and systems must be built for tomorrow. Your system is business value, not the current product you're currently creating. Your company's future relies on that fact, developers, projects managers, architects, management needs to understand this.