Well, it depends. However, more often than not the answer is no, it is not good enough.
Imagine your working on implementing a 'fix' for a 'show stopper' issue under an 'aggressive' dead line. I bet this does not sound too far fetched?
I would bet that you are not particularly comfortable cranking out a quick work around solution, yet I am sure that you find the quick fix so damn tempting.
Why is that? For one thing, the client probably wants this issue fixed yesterday! Deep down, they may not care how it is done. The bottom line is the sooner the better. Of course, doing it right is implicitly assumed but, this is usually sacrificed in the spirit of the Now. In fact, we are often rewarded for getting things out fast. Perhaps there are financial incentives for getting things done on schedule? In my opinion any sort of incentive tied to a schedule is a smell indicating that the schedule is just not right.
My colleague Dmitri Dolguikh recently pointed me to a great article concerning how costly quick fixes can be. I found the last two paragraphs particularly interesting:
I whole-heartedly agree with this, however, the reality is that being a true professional is not easy and, depending on the environment, may not be realistic 100% of the time. There are too many opportunities lying in wait to distract us from this ideal. In my view, a true professional is analogous to the notion of a responsible developer. To quote a recent post by Kent Beck on the XP mailing list:It comes down to a matter of professional ethics. Software developers are often disparaged for being sloppy, slow, and unreliable. Whole IT departments and product develoment teams carry the weight of appearing incompetent and moribund. Why? Because they succumbed to the seductive idea that quick and dirty solutions are faster in the short term.
True professionals don't work that way. True professionals keep their code clean at all times. True professionals write unit tests that cover close to 100% of their code. True professionals know their code works, and know it can be maintained. True professionals are quick and clean.
I try to do an excellent technical job but I also work to make sure that what I am doing fits into the larger business...If the technical concerns and the business concerns appear to conflict, I work to find a mutually beneficial solution but finally I follow business imperatives over technical ones.We work within the constraints of our current environment. Although the true professional definition as put forth by Bob should be an ideal that we continuously strive for, it may not always be achievable. In those cases, does that make you less responsible or professional? I don't think so.
We cannot solve all the problems of an organization, but we can do our best to help steer them in the right direction. Sometimes this requires a compromise.
5 comments:
I agree to some extent, but I think this line of reasoning could be used as a rationalization for more compromise than you intend.
My take on this is similar to my take on 'technical' user stories. Sometimes they are a necessary alternative to real user stories (ones that can be defined from the user perspective), especially if you're climbing out of a hole of technical debt.
However, they are necessary much less than one might think. Usually there is another way. We must be careful not to slip down the slippery slope and 'compromise' more often than necessary.
And, above all else, we must not forget to dig ourselves out of the hole we're in. If we start defining technical stories simply beccause it's easier, rather than because it helps us get out of debt, we're handing ourselves a whole new raft of problems.
Likewise, if we're sacrificing the long-term interests of the business (as represented by a sustainable code base that's not full of quick fix on top of quick fix) based on short-term political constraints, we must ensure we are building trust and managing expectations, so we will be faced with less powerful politics next time.
It might be necessary sometimes to accrue technical debt, however this should not be done lightly.
Technical debt is a big risk. Technical debt leads to uncertainties in the code base: generally it's hard to determine debt's size and it's impact on the rest of the code base.
By acquiring technical debt we make it harder to keep our promises (such as iteration goals). This leads to erosion of trust and paves way to office politics and turf wars.
We cannot change the whole organisation overnight, but this shouldn't stop us from trying to make improvements. Our leverage (as software developers) is the code base we are working on. By refusing to accept increasingly more technical debt we have a chance to improve the relationship not just between developers and product owner, but also between other parts of the business involved in the project.
Ryan, I agree with you. We do need to be very careful as to what compromises we make. One of reasons I wrote this was to start exploring my feelings of disappointment as I try to live up to ideals such as Bob's true professional.
We must continuously strive for improvement, however, we must do it in a way that is not too disruptive to the current working environment. This takes, time and I tend to find myself getting impatient.
Dmitri, perhaps we can generate more trust by making certain compromises. However, I do agree that we should accrue technical debt liberally.
Dmitri, I left out a very important word in my last comment: 'not'.
The comment should read:
However, I do agree that we should NOT accrue technical debt liberally.
Post a Comment