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

The best thing is probably to promote them to management so they can't do quite so much damage.

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!

Answer 4

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 5

The problem is most people don't even know about software design other than the most basic concepts and drag and drop style development. For every one developer who researches and educates themselves on all the best new concepts and technologies, there are ten who go home and don't look at a PC. You have to teach them.

Answer 6

Show them! Let them do a small module in "But this would be easier." style while you do it the right way. Then ask them to make 2 to 5 changes to the requirements (it must be them making the changes) and have a timed contest on implementing the changes. It may take a day or two but they will get it. If you don't, you will have the same discussion on every new project or task.

Answer 7

You could try an analogy on them....

The rules of chess are pretty simple. You can teach them to a child: "the horsey moves like this", "the castle moves like this", etc.

If that's all you know, you can play some chess and probably have a good time, but someone with a deeper knowledge of the game is going to wipe the board with you every time. You'll get beat so bad it won't even be fun anymore, because you'll have no idea how they're doing it.

The same principle applies to programming. Knowing the syntax of the language and a few simple data structures is enough to get you a working program, but you're not going to have much luck with a large-scale application that has to survive multiple release cycles.

Chess has set openings, attack strategies, etc. We have Design Patterns.

Answer 8

http://catb.org/jargon/html/L/LART.html SCNR, etc. pp ;)

Answer 9

I actually hate to take the dissenting opinion on this, but...

To quote Van Halen (quoting cliche), "there's a time and place for everything." While I certainly don't advocate writing badly, ever, sometimes you do need to just get it done, and find that happy medium between robust/enduring and hacked/documented. (The documented part being particularly important, on two fronts: one, that you clearly indicate that whatever it is you're doing is being done simply in the interests of getting it done and is taking certain shortcuts; and, two, a rough idea as to what the more correct way of approaching the problem might be.

As programmers, we often strive to write the perfect code (well, some of us do), and sometimes lose sight of the big picture - there are any number of reasons why it might be ok (on a level) to play fast and loose with the code, while minimizing the impact that will have down the road.

Please do not use this as justification - the 80/20 rule applies here, of course. Most of the time you absolutely want to crush any shortcuts along these lines; but sometimes...

Answer 10

I designed a big and complicated system about five years ago. I spent the next five years injecting myself into every project that affected "my" system to keep the barbarians from sullying my architecture. As long as I applied constant, unrelenting pressure I was able to keep the architecture pretty clean, but I was fighting a losing battle. Here's why:

1) Most people are judged on whether they got the job done today. Nobody has ever been reprimanded because they cut a corner (or two) three years ago to get a project out the door on time. On the other hand, many people have been reprimanded for not getting projects out the door on time.

2) You may want to keep the system tidy because you have a sense of ownership over the code, or the application, or the users, etc. Many people will not have a sense of ownership and therefore are all too happy to hack something up so they can be done with it. You can lead a horse to water, but you can't make him care.

3) If you do convince everybody to maintain the code properly, new people will come on board and need to be taught how to do things right. So even if you're successful you can feel like you're failing because you're always fighting the same battle against new opponents.

4) You might actually be wrong. Would it make financial sense for Microsoft to spend twice as many programmer hours making MS-Paint robust and maintainable? Sometimes an ugly hacked-together system is Good Enough. Most good programmers have trouble understanding this, but this is usually because they're good programmers.

5) I swear there are some people who take perverse pleasure in hacking things together either because they can do it faster, or they'll be the only ones who understand it, or they have a childish need to break rules. You can't reason with these people, and the more time you spend arguing with them the closer the project deadline gets, which will force you to hack something together anyway.

6) There's a good chance you understand the system better than they do. What looks like an ugly hack to you might look like "treading lightly" to a person who isn't as familiar with the system. Or the extra effort to make the code robust will protect the programmer against a problem he's never had before and therefore can't grok. You don't learn to check return codes until something goes wrong because you didn't check a return code. At that point it stops being "extra work" and starts being "required work".

If you have a small, tight development team it's possible. But the bigger the organization the less likely you are to succeed. If you manage to get a 250-person IT shop to value doing things right over doing things fast then your powers of persuasion are legendary.

Answer 11

Tell them to read (not that they ever will) Encapsulation theory: http://www.edmundkirwan.com/