For the workshop on technical debt, everyone has to write a position paper, give a case study, do a talk, OR do a tutorial. (“One of the above.”)
That includes me.
So I have decided to write two position papers, and, maybe, show some of the process on Creative Chaos.
The first position paper will attempt to describe the systems issues in technical debt – why it happens. The second will be about communication and metrics.
Here’s my first thought about the systems issues:
Some things to consider about tech debt:
1) Our educational system, for the most part, is built on one-off projects. Students build a program that inventories their CD collection. It doesn’t work well – it even has some bugs – but it is good enough to demo and get a B+. I would go so far as to say that the majority of undergraduate programming assignments can get hacked out in a weekend with a lot of Pizza and Caffeine. And, if not, well, you can always turn in some absolute garbage, get a D for the project, a C for the class, and a B- overall for the semester.
This means that students never have to live with the pain of maintaining the pile of mud they write. Thus, our first exposure to programming actively rewards us for tech debt.
2) Technical people absolutely stink at communicating about tech debt. First, we get grandiose ideas about generalization and abstraction that management does not (and should not) trust. So when we whine about how we need more to “fix this right”, what is management to think but that we are just creating yet another castle in the sky?
3) Technical people have more power than they realize. The easiest way to prevent a clever hack is to not make it. Sure, you might not be the “go to” guy anymore, but recognize what the go-to guy gets: The toughest projects. That, and pigeonholed into a technical career path.
4) Non-Technical People don’t realize what they are asking. Sure, the project manager asks if there is “anything you can do” to go faster, and has no problem with you taking “shortcuts” – but when the code falls apart in production, is he going to stand up and say “I authorized that, I knew it was risky, it was my choice.” Or is he going to say “I asked him to be fast — not irresponsible.” Catch the different there?
So don’t be irresponsible. See point #3.
4) For the most part, North American business is optimized to create short-term results at the expense of the long term. In other words, when you hear “Just do it quick, we’ll do it right later”, it is fair to ask if the company ever – *EVER* – actually does it later. If the answer is ‘no’, recognize that “just do it fast for now” means “just do it hackey for always.”
5) A lot of old-school, “get everything right up front” people are going to use tech debt as a tool for insisting on Big Design Up Front. That is not my goal. I see BDUF projects creating a bunch of documentation and plans and things that need to updated. That up-dation is drag on the project – or, in other words, interest. Compared to other schools of big, heavyweight design, my approach leans toward “I could do the whole dang project before you finish your design.”
One easy way to move fast is to travel light.
Which leads to –
6) Just Do It. If I all the time spent whining and complaining that we need to “do it right” were thrown into just doing it – if for just a couple of weeks we gave up coffee breaks and the watercooler and spent time just plowing throught code – we could get it done.
Overall conclusion: Courage is a cardinal virtue for a reason.
Next question: How do we change the system so that courage (and doing the “right thing”) is encouraged and rewarded?
—-> That is my rough and sloppy 1.5th draft. If someone were to attend the workshop with just this, it would be the minimal amount of effort required. Of course, I intend to improve it.
But who cares about that. What do you think of my talking points?