It's amazing that you get so defensive over "learn the business". I never said to be a meek dev. In fact I clearly state that you should attempt to change minds with principled arguments that have the business in mind.
But based on my experience, that's not what I've seen. I've seen devs fight to do a completely rewrite that management won't fund because everyone wants to continue to use the old LOB solution. The devs argue about how the old system is a rats nest and uses archaic technology. But the business says that its doing the job, why do you want us to switch to something that lacks the features we need, just because it uses REST rather than SOAP (whatever that means).
And I've been brought in to consult on many of these disputes and probably 8 out of 10 times the "ugly" code is perfectly serviceable. What I've often done is shown how one can incrementally improve and rearchitect the existing code with no downtime... and probably more than half the time this ticks off the architect. His big dream was to do this monster rewrite that I've just shown is completely unnecessary.
At the end of the day maybe I've hurt morale of the dev team, but janitors don't get paid to not clean bathrooms (not that we're janitors, nor is there anything wrong with being a janitor, but you get the point).
I apologize for being overly defensive, but I've unfortunately lived through all of what I was saying. I do agree with your Janitor analogy in that at the end of the day you're paid to do a job. However the problem often lies in situations where developers are hired for their expertise, but they aren't allowed to utilize it to do the job properly and instead are just asked to get it done.
I guess if I hired engineers who were capable of doing a complete re-architecture of a system, but forced them to put in "ugly" code that is perfectly serviceable - I wouldn't expect them to be around very long. I don't speak for everyone, but I do strongly believe that those that do this for a job and paycheck will be fine, if not happy, working on ugly code to keep things going. Those that do this for the love it, whom in my opinion are often better programmers, won't. At least, not for very long.
Still, there is definitely merit to your statements, especially when it comes to devs dreaming of re-architecture and instead having to settle for a small change. I appreciate the follow up.
Thank you for your follow up. Clearly your experience is far outside my world. I've never heard of an outside consultant being brought in to second guess the company's "architect".
It seems like you mostly move among bad developers. I don't think your experience is relevant to most of the developers reading HN.
Obviously, a full rewrite not a good idea in most cases as Spolsky eloquently argued.
PS: I didn't detect any "defensiveness" (you know, the catchall passive-aggressive term that is used to use to imply that the other side has a weak hand without backing it up) in the post you were responding to. It rang true to me.
I don't think I move among bad developers, per se, but when I consulted I generally worked at places that weren't software companies. HN is filled with developers who plan to build companies (or work for companies) whose core business is to build software and either sell or have that software be the key part of a service. A lot of the places I did consulting for, if all of their in-house software stopped working, they could probably still do business, but a lot less efficiently. Most companies are not "about" the software just like they're not about the desks in the office.
And actually... quite often I wasn't brought in to second guess the architect. Many times I was brought in at the request of the architect. But yes, most of the time you're brought in because they lose faith in the architect or team. If you see me stop by to do a simple audit of your code, you should probably get your resume ready -- well not really, as I don't do any consulting any more.
But based on my experience, that's not what I've seen. I've seen devs fight to do a completely rewrite that management won't fund because everyone wants to continue to use the old LOB solution. The devs argue about how the old system is a rats nest and uses archaic technology. But the business says that its doing the job, why do you want us to switch to something that lacks the features we need, just because it uses REST rather than SOAP (whatever that means).
And I've been brought in to consult on many of these disputes and probably 8 out of 10 times the "ugly" code is perfectly serviceable. What I've often done is shown how one can incrementally improve and rearchitect the existing code with no downtime... and probably more than half the time this ticks off the architect. His big dream was to do this monster rewrite that I've just shown is completely unnecessary.
At the end of the day maybe I've hurt morale of the dev team, but janitors don't get paid to not clean bathrooms (not that we're janitors, nor is there anything wrong with being a janitor, but you get the point).