Brief Response to Corey on Software Craftsmanship
Corey’s blog’s comment box is failing, so posting my response here. Read his response to my post for context. Below is simply cut-and-pasted from a comment I was trying to leave on his blog:
Hey Corey, thanks for the well thought out comments. Let me consider my response and most likely post it on my blog, but while I'm writing here I'd like to describe a very real scenario I'm faced with right now that plays into my thinking on this subject.
I am providing some coaching to a small business owner and software developer. This shop has been around for about 18 years and has a shipping product written in a legacy (as in, no longer shipping) platform. He has chosen to move it and his team to the C# and .NET platforms, and wants my assistance getting there.
My personal experience has led me down the path of TDD, XP, Lean Development, and writing SOLID (a la Uncle Bob) code. I very much prefer to work in this environment. However, in working with this client, who has only the budget for a few hours of time here and there, I know it will be a very long time (at this pace) before this team can get to any kind of proficiency with this environement. They're very much data-first, two-tier, forms developers. And due to the pressure from the current economy, they need to ship some new things ASAP (yesterday, ideally).
If it matters, this client is also a friend of a friend, and one who has placed their trust in me to help them make the best decisions for their business in terms of how to move forward.
Now, it literally pains me to choose what I consider to be less-than-ideal coding practices or frameworks as being the best way forward *for this client* but I believe that the reality is that that is what is called for. They need to ship product now. Their skills are what they are. They don't know unit testing. They don't know agile. They know data modeling and forms dev. And they don't have the budget for me to train the whole team properly or for my team (who does have these skills) to do it for them.
So, I can stand on principle and leave them high and dry. That's a valid option and perhaps one the Amish craftsman might adopt if their friend asked them for advice but didn't have the time to invest to properly learn all the master's skills before the job needed done (and the friend needed to do it themselves despite their own admitted lack of the master's skill).
Alternately, I can view my role as being larger than just a coder, but as an asset to the client's business, and as such I can try and help choose the path that leads to the business' short term success (e.g. shipping new product). That's what is being asked of me by this client, and I don't think it's dishonorable of me to do right by the business even if it means using tools that I personally would be less productive with.
And the client does acknowledge they have a long road ahead and is eager to learn. But they can only invest so much time and money in learning now - they still have to produce something in the very short term.
How would you respond in this situation, Corey?
Comments
Corey Haines said on 24 Feb 2009 at 12:02 PM
I will take some time to think about an appropriate response and post it.
Kormt Sereg said on 24 Feb 2009 at 12:13 PM
Were I a developer you worked with on this project, if I were asked of your capability, "Steve saved our business by helping us write better code. It was clear he had much more to teach us, but he didn't let that distract."
And though no one else be willing to apply the label, I would call you a software craftsman for it.
Jeff Putz said on 24 Feb 2009 at 11:21 PM
I think Corey's post was largely nonsense. He spent all kinds of time questioning your personality and making assumptions about you, so if he had anything interesting to say, it was lost in that.
I struggle every day trying to deal with the balance between the "right" thing to do and getting things done. Living in a world of high ideals just gets you high... it doesn't always solve the right problems.
Dave Hoover said on 25 Feb 2009 at 9:39 AM
Your client's situation sounds unsustainable. The cost of the teams' ignorance and the codebase's poor quality are greater than the value of the software. Therefore, they are trapped in a vicious circle. If the business can generate a big enough chunk of money they will have an opportunity to do the right thing by improving their team and their codebase. That is probably not realistic, so their best bet is to begin replacing their team with people who already know what they're doing.
Kormt Sereg said on 25 Feb 2009 at 2:01 PM
Dave,
It sounds like Steve's client's intent is to improve their team. Is your suggestion that the surest way to do this is to replace its members rather than teach them? I do believe there are more cost effective strategies beyond people-as-tools, particularly when this is a team that trusts you to improve them beyond just financially.
ssmith said on 25 Feb 2009 at 2:30 PM
@Dave,
In this case, the team is small and the one who will be doing most of the work is one of the company's owners, a developer with 20+ years of experience but not in the .NET world. I don't think replacing him is an option, and as a small business owner I don't think he wants to replace employees that have been part of his team for years (and have substantial knowledge of the legacy system he's migrating) with folks who may know .NET and perhaps TDD/DDD but not his business or his existing app.
I do agree it's a very challenging situation, though. It will be difficult to bring the application forward while supporting its existing clients and training up on staff. We just met again today, though and we're making good progress. I showed them Dependency Injection as a technique, and we also looked at some tools they've purchased that will do a lot of the grunt work of migrating and re-creating chunks of the legacy app into .NET/SQL Server. A mix of training on best practices and simply moving forward and getting things done seems like the way to go, and is working well thus far.
Jon Kruger said on 25 Feb 2009 at 7:23 PM
I see the point that you're trying to make... that in this case, the client is accepting technical debt knowingly because the value of getting the project done now outweighs the cost of having to deal with the lower quality code down the road.
We have similar situations all the time (I work for a consulting company). Usually this comes in the form of projects that we take over that really need to be rewritten, but they can't rewrite it right now because of time/money constraints. So we're forced to deal with a code base that does not lend itself to testing or other good practices, and we have to make the best of it. We don't turn down that work just because we can't do everything the right way, even if we really think it would be a better move for them to start over and rewrite it. But I'm not less of a craftsman for doing that. Frankly, these days if my company decided that we would only write code that meets our standards, we would run out of work and we would have to lay a lot of people off.
At the end of the day, businesses have to make money. Sometimes they will make more money by scrapping and rewriting and sometimes they will make more money by applying another band-aid and hoping for the best. But the CIO making that decision is doing his best within the parameters that he has to deal with, and we have to support them in whatever way they need help.
Dave Hoover said on 26 Feb 2009 at 9:45 AM
My recommendation for slowly replacing the team with developers who already know what they're doing was based on my assumption that this team matched the worst case scenario that Steve had in his original blog post: "resistant to changing their typical modes of writing code". If this team is coachable, and the main developer is an owner, AND they've brought in someone to help improve things, then incremental improvements seems like a viable approach. That's great news.
Corey Haines said on 01 Mar 2009 at 10:34 AM
I put down some thoughts on the situation, as well as some advice. programmingtour.blogspot.com/.../stuck-between-r
I am waiting for a response to the more egregious generalizations and misunderstandings in the original post. I'm looking forward to better understanding your position.
One question, was this the business owner who talked about only being interested in people who has the dichotomy in his mind between writing elegant code and just getting it done 'with minimal fuss?' Or some of the other 'successful business owner' comments?
Paul Beckford said on 05 Mar 2009 at 9:14 AM
Coreys summary "a rock and a hard place", just about sums it up.
It takes a number of abilities to succeed in business. Craftsmanship speaks to creative competence. Then there is business competence and management competence and ... It sounds as though your client is struggling in a number of areas.
My question to your client would be "What have you been doing for the last 18 years to prepare for this moment?"
If the answer is nothing (which seems to be the case), then the move to .NET will take a lot longer and be a lot more painful than anticipated. If your client is a friend, then they will appreciate a good dose of honesty.
Paul.
disgusted said on 07 Mar 2009 at 10:58 AM
All hail Corey Haines! The great software crasftman! Given that name by himself!
What will be really nice is when (probably some time later this year) he wakes up and begins calling himself Corey Haines - Software Guru and All-Knowing Programmer Deluxe. Praise to him!