How to support design decisions?

Question

There are bad design decisions.
On the same pitch, being a senior engineer can sometimes be hard. Youngsters have awesome and radical ideas, which a senior engineer wonders whether will work on the field, and if it is worth spending all that effort. Experience suggests that these are short-term solutions are very expensive in the long run. However, it might be hard to convince otherwise.

How does one go about in this scenario? Patterns are a good start, however, it takes a little experience to figure out where to apply a pattern, as a newbie might restate the problem to fit the pattern. Also, patterns do not help at coarser/component levels. Another idea is to refer to a good design that works in the field, and is outside the organization. The problem here is that sometimes drawing a parallel might be hard. Are there any other ideas?

Answer 1

Ask Questions Based on Experience

My most powerful tool is to ask questions based on experience. When the junior programmer comes in with a design and you see a problem with how it will work in reality - ask the question "how will this work, given X element of reality?" Don't say - "this won't work because of X element of reality".

Often that has ended the discussion without conflict as the junior engineer goes back to the drawing board.

Be open to the answer

Once you've asked the question, be open to hearing an answer. Junior developers have actually taught me plenty about new technologies I didn't know enough about. I don't take their word for it - I do my own research, too - but sometimes they see things that I don't. Be open to the answer to your real world problem - they may just surprise you.

Pull in the big picture of the project

One of my biggest battles is usually developers who want to do their own pattern for design that it outside of the pattern being used in the rest of the codebase. It may, actually, be just fine in terms of that isolated area, but it is glaringly different when compared to the rest of the codebase, and my experience tells me it'll be a maintenance nightmare.

At this point, I push the developer to see the big picture with a few more questions:

• Are you saying all the code should be refactored this way?
  • If yes, then how much would that cost? Will we still meet schedule?
  • If no, then why is this area so strikingly unique that it should work different from the typical solution?
• What's the benefits of this vs. the existing way of implementing things?
• What will be the impact when someone who isn't you has to maintain that?

That's not to say that every new idea for implementation is bad... but there IS a value to no changing a known quantity and developers need to think about it before changing models midstream.

What's the worst that can happen?

There is no teacher like experience. If the junior engineer is developing something central and critical to problem, no way will I let a radical design fly without a ton of team scrutiny. But if the engineer working in a prototype, a tool or some other side area, it may be a good opportunity to try something that sounds wacky, but may just work - after all, you have to try new stuff sometimes...

Answer 2

Junior developers tend to either drastically over engineer or under engineer a solution.

Neither outcome is desirable. The only way to find the middle ground is real world experience in doing these extremes and seeing the disasters that are the outcomes of both extremes.

The general end result of both extremes is un-maintainability.

Over engineered designs introduce un-needed complexity, extra code to debug and write test cases for and to have to understand and maintain. This leads to maintenance nightmares.

Under engineered designs suffer from not being flexible enough to adapt to new requirements easily in a given timeframe, if at all. This is the other end of the maintenance spectrum.

The balance that needs to be achieved is hard to teach to someone without any scope or understanding of these outcomes. Experience gives you that perspective to know when enough is enough design wise, and to know when you are doing too little.

In the end, under-engineering a solution is less risk and less costly from a business stand point, because it is closer to the "you ain't gonna need it" (YAGNI) principle. And if you never really need the more complex design, you haven't wasted hundreds of man hours.

If you under engineer and you need to re-design to add new features, you only have a short amount of time that gets thrown out and work redone.

Where as spending weeks implementing a overly complex design that never bears fruit, you not only have lost those weeks you pay for them over and over maintaining code that isn't appropriate.

A good rule is If it smells like something is overly complicated and will be a maintenance nightmare for someone new to the code base don't do it.

Answer 3

The ability to make design decisions is what separates software engineering from programming.

Important design decisions should be made based on facts and data, and should support the design goals.

You can perform options analysis to help make important decisions. To perform an analysis, first decide on measurable (or estimable) criteria that you can use to base your decision on. For software, these criteria can include cost (resources required to develop, deploy, configure, and maintain a specific design), performance (will the design meet time and memory constraints), risk (can the design be implemented in a way that it will work), security (will the design support security). Other criteria to consider include scalability, adaptability, portability, flexibility, extensibility, etc.

Then, assess the design options with respect to the factors you have decided to use to make the decision.

Note that good options analysis takes time and effort, but it should be used for major design decisions.

Answer 4

If a senior can provide a good reason for why their design is reasonable, and defend any issues it might have, a smart junior will go along with it. When a senior says "I have done this in the past" with no further explanation, a junior hears "I have done this in the past and it was so clever that it ended up on The Daily WTF".

A lot of seniors today rebelled against the previous generation as well. Look at Waterfall. Look at no-tests-whatsoever development. Look at goto design. The ideas that unseated the old standards came along because many of the senior developers today had a fresh look at the wacky methodologies of their seniors when they were juniors.

That being said, for every great idea a junior has, there are a hundred terrible ideas. It is a senior's job most of the time to say "Nice try, but that will not be feasible because of X and Y". Without that feedback, however, a junior will often assume that they have come across one of the "goto" dinosaurs they read about on the Daily WTF. This does not describe most seniors, so give them a reason to see how you came to a particular pattern. Show them that you learned enough in 20 years to have a far more in depth knowledge of design, by actually explaining how what you are doing is better. Juniors do not have the experience to "just know" what the right pattern is. They (we) need to know why.