"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.
