Developer: “We could improve the error message when that happens, if we are going to fix a bug in that area, right?”
Boss: “No, do not spend time on that, we are going to rewrite the whole administration interface in the future.”
Developer: “In the next release you mean?”
Boss: “No, not the next release. We got to add feature A and B, and the sales department desperately wants C so we can sell to Big Customer.”
(a couple of releases later)
Developer: “So we are back in the administrator interface again. I still think that error message is bad.”
Boss: “I agree, but we got this big rewrite of the admin interface, remember? Do not spend time on it now.”
Developer: “So when will that rewrite happen…?”
Boss: “We will see. Things have changed, we gotta get more features into the product, we cannot focus on this now.”
Developer: “…”
The Castle In The Sky. Nice to dream about. Not so nice in reality. [svg]
And that is not a good way to improve stuff, of course not in the short run, but also not in the long run.
Why? Because The Big Rewrite often does not happen–at all. There will always be that other pressing need from sales, that is more important than improving for the people that really use your software: the users.
The Big Rewrite is another way for bosses to say “that is not important”. And not only bosses use this technique; also developers not interested in improving the software for end users use this–quite ingenious–argument to keep attention away from problems that actually could be solved to improve the software – both in the short term and in the long term. Please read the chapter “Use Your Software (product)”* for more material on this subject.
What to do?
How do we reason or explain to the boss that we have seen his (or her) evasive maneuver, “The Big Rewrite”?
To begin with we must understand that it might not be intentional. There is a saying: “Never attribute to malice that which is adequately explained by stupidity.” (Hanlon’s razor). So do not assume it is a devious strategy.
Instead, you could just explain the problems with “The Big Rewrite” – that the risk with painting a castle in the sky is that a culture of “don’t improve things” will grow in the team, since it will be a wasted effort.
I believe small improvements are not wasted effort. In fact, my experience is quite the opposite. It is the details that make good software better than mediocre software.
End note: The Big Code Rewrite
A very similar argument can be heard when it comes to improving code: “Just leave the unused methods/arguments/classes/configs/settings; we are going to trash that whole layer of functionality anyway”. And basically the identical story could be told in this scenario: quality is in the details. Please read about “Scouts rule” for more on this.
* I plan to write “Use Your Software (product)”; link will be provided when I have.
