The real challenges of building the right thing right

Suppose you're in the following situation.

• You and your team are supposed to start working on some important architectural changes that were long due.
• Your team is then asked by your manager to help build an important feature that requires the unique skills of your team, and which you think will take 5-6 weeks to build plus two weeks to support quality assurance. That feature is the final check in the box for the company to send a big fat invoice.
• Accepting the task will mean that those architectural improvements will get postponed even more.

Now suppose you do understand the need for this and know management has no other options, you agree, and commit for eight weeks. Over those 6 weeks of development, you make a lot of little technical decisions, some good, some bad. For instance, introducing a couple of HTTP APIs on top of ASP.NET controllers rather than using a proper OWIN pipeline. Or struggling with a client-side control and the right framework that fits with it, resulting in JavaScript code that’s difficult to test with Jasmine.

After delivering the feature, it's time to focus on those architectural improvements again. But wait, should we not first repair those bad decisions we made during the last 6 weeks? You wonder, what's more important? Well, those architectural improvements will open up all kinds of significant opportunities that will improve the performance and scalability of the system. On the other hand, using an OWIN pipeline for those HTTP APIs serves as an example for other teams to build more efficient code. Then let's ignore that untested JavaScript for now. But you can’t really do that either. You yourself have been instructing teams to design all JavaScript code in a testable fashion. "So what", you think? You had a deadline, didn’t you? But, do you remember what you told that team when they had the same excuse?

Although this is a bit of a contrived scenario, it is a situation I'm pretty sure you will recognize. So how will I deal with such a situation? Well, I'd probably skip the OWIN pipeline conversion. Although it's nice to have a reference example for the other developers, I might be able to pick this up as part of a future story. Or, if the opportunity arises, I might be able to convince another developer needing similar functionality to include in his work. But refactoring the JavaScript code to make It testable is not something I would postpone. How can I ask other developers to follow those rules if I don't follow myself? I really believe in practicing what you preach and building the right thing right. So only after I've finished this I would switch my focus to the architectural changes.

So what do you think? Would you follow the same line of thought as I would? Let me know by participating in the Disqussions below. Oh and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.