How do you get people to value abstraction and flexibility over "just getting it done"?

Question

I sometimes have difficulties with other people who wish to solve a problem when they wish to skip the official interfaces and access underlying implementation details directly.

They argue that doing so will allow them to solve the problem more quickly. I argue that doing so will cause our architecture to become more tightly coupled and difficult to change as new requirements emerge.

I point out all of the work that went into the current design and the philosophy of the design and the value of flexibility, the cost of trying to maintain and change brittle code, the value of encapsulation and data hiding and layered architectures and being robust so that small changes in the specification lead to small changes in the code. And they say "But this would be easier."

How do you handle these people?

Answer 1

Have them work on some legacy code fixing the bugs in it. This is pretty much how most people I know have learned these really valuable lessons ... the hard way.

Answer 2

Convince them that taking shortcuts is a false economy.

Explain that the initial coding effort is less than 30% of the initial development effort, and less than 10% (in my experience) of the overall project effort (including maintenance).

If they remain unconvinced, and you have the authority to do so, then tell them to do it your way. If you don't have the authority, then do nothing else. Eventually your supervisor, if she is worth anything, will recognize this and you will then be in the position of authority.

Answer 3

"Easier" when? Now, when everything isn't in a state of flux? Or three months from now when the customer's requirements have changed and they've got a 'solution' that isn't a solution any longer?

I'm not much for structure and rules for the sake of structure and rules, but it is good to know A) who is driving the boat B) what the rules are and C) why we chose to do it this way.

In my shop we don't like to have to rewrite code because we screwed up and hardcoded a bunch of stuff or created some brittle 'solution' to the problem. It tends not to be any harder to follow the more flexible approach once folks realize that it will reduce the frustrations later on when things are turned upside down by a bunch of requirement changes. We code for the 'long haul' not for the 'need it today', typically, so the design is made for a reason and the design is followed for the same reason.

I spent a week of my life (7 days straight) rewriting a module because I was in 'get it done quick' mode. Seven days of grueling time, 10-12 hour days doing it the right way, late in the game, when I could have been watching the Super Bowl. That stunk. I learned a lesson there. It may be that your 'friends' will need to experience that sort of eye opener themselves too.

Best of luck!