- You must limit your development team to those people with the experience and capability to consistently write well-crafted code.
- Because this talent pool is smaller, losing an employee is a greater cost. Thus, you must be willing to compensate your "craftsmen" at a level which minimizes turnover.
- If you choose to hire junior employees who show the skill and interest in becoming "craftsmen", you must commit the time to mentor them, and accept the fact some of their development efforts (especially at first) will not "make the cut" for inclusion into the codebase.
- You will not be able to take advantage of "bargain" developers. If a
body-shop (on-shore or offshore) promises craftsman-level work at
college-grad-new-hire prices, you should probably treat them the same as
you would someone selling you a 1-year-old Porsche for the blue-book
price of a 10-year-old Volkswagen.
- You must take the time to think before you code (or
design). Research - are there commonly-accepted approaches to meet your
requirements? Consider your design at an abstract level - does it
mesh well with the framework in which it will run? This means initial
development takes a little longer (compared to the "just do it the first
way that comes to mind", or the "this is the only way I know how to do
this" approach).
- You must be willing to refactor code which fulfills the system requirements, but is poorly-written.
- You must have the discipline to maintain these ideals, even when deadlines loom near. You must be open to the possibility of sacrificing some functionality in order to meet a deadline.
For much of my career, I was too busy learning my craft to really think about things at this level. However, once I had progressed to the point where I could recognize and produce well-crafted code, it really made me angry: why were there no companies who were willing to make that commitment to high-quality code, in order to reap the benefits?
- Well-crafted code has its own "beauty", and gives the developer a sense of accomplishment and pride.
- Well-crafted
code is more easily understood by other developers (if they have a
comparable level of expertise). New employees can be productive sooner,
and existing employees can maintain each others' code with less
knowledge-transfer time.
- Well-crafted code generally has fewer bugs (I'm not sure whether that is a factor of the quality of the code, or the experience of the developer). Bugs which do occur are usually quicker to diagnose and repair.
- Well-crafted code is easier to extend. Future enhancements to the product can be made more quickly, and the product will be able to "withstand" more enhancements before its overall stability / reliability / performance takes a hit.
... Wait a minute... Those last couple of things are from the list of "costs", not "benefits". What happened here?
That's when I realized - I've been looking at this purely from my own perspective - that of a developer who loves crafting code that works in concert with its environment, understanding design patterns, and thinking about and discussing the best ways to approach certain abstract problems. From that perspective, the costs of well-crafted code are very small - so small that I viewed many of them as benefits! And of course, the benefits are very large - "a sense of accomplishment and pride in what you do" - Abraham Maslow would agree.
If I'm going to try to understand why well-crafted code isn't a corporate priority, I'm going to have to look at this from a corporate perspective. I've never been much of a business-person, so that perspective doesn't come easily to me. But I'll give it a try in my next blog post.
PS: if you currently work for a place which is truly committed to well-crafted code, that's terrific - I'm jealous of you. You're in an extremely rare situation. Keep that in mind if you consider leaving for "greener pastures" - you're already about as green as it gets!
Hey Mike, you hit the nail on the head in two ways: all of your points are true but from a craftsman's perspective, and yes there is the other perspective of management. Having been on both sides, here is what I see of the management perspective. If I put a negative tone on it, it just shows my bias. :-)
ReplyDeleteWell crafted code takes too long in today's "gottahaveitnow" "it's all about this quarter's earnings" corporate mentality. I often rant that in the "holy trinity" of Cost, Quality, and Time (schedule), management will sacrifice quality. Every single time. Every. Single. Time.
I look forward to your next installment! Great blog so far.
Thanks, Sharon! I suspect we have some of the same biases when it comes to corporate decision making, and the victory of short-term-cost-savings: every. single. time. :)
DeleteI finally got my next post up, and I really do try to put on my "what would I think if it were my job to balance the corporate books" hat. Hope you like it.