That is indeed a rough situation. Let me see if I understand the facts correctly before I say what I would do
- Small business owner/developer decides to move his team to .Net using C#.
- His team is unskilled in writing maintainable systems on this platform.
- He has to do this switch ASAP using the team he has.
- He only has money for a few hours of your coaching time 'here and there' to get his team and product onto the .Net platform.
- He's a friend of yours
But, that last point is a stinker. He's a friend, so here is a longer answer.
This sounds familiar. I'm sure that a lot of the people who read your blog and mine have seen this situation. Most of them have probably seen the outcome, too: a system that will very rapidly get to the point of where changes take too long to implement, resulting in the entire system needing to be rewritten. This isn't accepting 'technical debt,' this is accepting 'technical bankruptcy.' In fact, to quote a well-known movie: "You keep using that word. I do not think it means what you think it means." I'd recommend explaining to them what technical debt is truly about (Ward Cunningham has a great explanation here. He coined the phrase, so his word should lend support to your recommendation. Hint: it doesn't mean "bad code, because we don't have the skills to write it better."
Well, this developer/business owner obviously has put himself in a severely limiting position based on most likely some bad choices. Let me outline a couple of the ones that I've seen before that sound like they might align with this situation.
1) Waiting until the last minute to make significant technology changes.
From the urgency in your post, I'm assuming that the switch to the .net platform needs to be done 'ASAP (yesterday, ideally).' So, a developer with '20+ years of experience' decides that it is best to wait until he is forced to move to a modern development environment with his application. The current platform is no longer shipped. Was this a sudden occurrence?
Solution: If your company depends on this product, make sure you keep your eyes on the future of it.
2) Assuming that you (and your team) can just 'pick up' a new technology.
Learning a new technology, especially a new programming paradigm, takes time and practice. I have met very few people who can jump to a new technology and be successful writing business critical applications.
Solution: You need to give yourself and your team enough time to achieve a reasonable level of proficiency in the target platform. This is done by looking forward to where the industry is going, figuring out a plan for where you need to go. Once the plan is in place, begin training your team. The time to bring a coach in is not when you are under the gun and the ship is sinking, but, rather, when you have time to train correctly. Sadly, in our industry, the former is far too common, and the latter is too rare.
3) Expecting that a few hours of coaching 'here and there' will be enough to bring the team forward.
Introducing new concepts to a team in the midst of a rushed product often leads to a less maintainable system than if the team continued with their original approach. SOLID concepts and their applications are often confusing to people when they are first introduced to them. This confusion often leads to misapplication of the techniques.
Solution: Get through the death march with the understanding that code written will need to be re-written. And, please, do not call this 'technical debt.' Call this throwaway code to counter bad decisions. Again, point them to Ward's video to explain what 'technical debt' really means.
But, those are just pointing out the bad mistakes. That's just one aspect of really helping. Since this is a friend, we want to help moving forward.
Since they only have a few hours of coaching, I'd highly recommend putting together a set of focused practices that will allow the team to more rapidly build their skills in the necessary techniques. Some of us in the Software Craftsmanship movement are starting to organize regular Code Retreats that focus on practice. These might be beneficial for your client. Other people are doing similar things.
Another idea: Rather than only talk to (or briefly code with) them about concepts, take the few hours that you have and prepare a set of exercises that they can use to hone their skills. I'm working on a set in Ruby, but you could probably port them to C# with a small amount of little effort.
The important thing is to give them structured forms of focused practice that will allow them to practice, outside of project work, the techniques that make up these concepts.
But, in all honesty, I truly believe they are setting themselves up for failure, and the best thing you can do is help them as much as possible with the realization that, when and if it fails, it will be not because of agile, not because of craftsmanship, but because of poor choices and lack of planning.
Posts
