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
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
you can’t really do that either. You yourself have been instructing teams to
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
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
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.