Architectural Niceties

"I'm not going to slip schedule for architectural niceties"

This is what my very-long-time-ago boss said to me when I suggested we make a change.  He was a great guy - very technical and had experience shipping and supporting all kinds of hardware and software products.  But the words stung.  I recalled these words on another project where I was designing something for another group in the enterprise.  They needed the design done yesterday so the schedule pressure was high.  They were already behind schedule.  When I suggested a change that would increase the robustness of the design, but would be more time, the systems engineer flatly rejected it.  "The engineer working on it only knows this one way on how to do things.  Besides we need to finish this."

Oh. 

Certainly, designing for today and not tomorrow is something I adhere to in practice.  In Kent Beck's Extreme Programming (http://en.wikipedia.org/wiki/Extreme_programming) he describes four values, one of which is courage. It does take courage to design and code for today and not for tomorrow.  We engineers love "what if" scenarios.  However, it requires a lot of courage to refactor something - to throw it away and rewrite it when it no longer works or is holding back progress in the overall system.  Management also needs courage to allow engineers to do this refactoring as sometimes it doesn't add any new functionality but allows the system to more agile to other required changes. 

One project I worked on we had management approval to rewrite a whole swath of code that was generated by an obsolete tool.  The tool and the company that sold it were gone but the code we had in our system remained.  When functionality had to be added we coded around this generated code creating solutions that were downright awful.  Finally we had enough and we wiped out the whole thing and rewrote it.  It took months with several engineers involved.  It was completely worth it.  And we had the courage to do it.

In another project we found out we did the wrong design.  Unfortunately we already released the interfaces and they could not be changed. So we added in another wedge of code that was somewhat duplicative but was the design we should have done.  I recently was talking with another engineer and she pointed out the problems in this code.  I cringed.  I remember having to do the work and was just horrified at the solution I created.  But hey, we were under schedule pressure.  We had to fix this and fix it quickly. 

So as much as I want to believe I take the architectural high road, I don't.  I realize I have to have the courage to refactor these things.  Off to talk with my boss…it is a different person so maybe he will appreciate architectural niceties.