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?

4 Answers 4


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

  • +1 for be open; in general, it is evil to discourage ideas. I have seen the ideas that sound most absurd lead to wonderful solutions. And for the worst thing, a story: We have an youngster who suggested that he will create a property file driven meta language for defining business logic to handle all XML payloads of the application: extensible enough for us to change things at run-time. As absurd as it sounds, I transformed the idea into using rule-bases, and was plenty helpful.
    – CMR
    Jun 13, 2011 at 21:20

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.

  • +1 for experience. This may be why many of the best developers have many personal projects - they've been practicing.
    – Michael K
    Jun 13, 2011 at 15:41
  • +1 for "the only way" part. However, I think business prefers under-engineering not because cost, but because it helps the functionality making the market faster. From my observation, over-engineering usually costs less than under-engineering in long run.
    – Codism
    Jun 13, 2011 at 17:35
  • @Codism, over engineering goes hand in hand with not invented here syndrome in my 25 years of experience, over engineering has always been a lose/lose scenario. And cost way more over the long run. Maintenance cost is 90% of the cost of a software project "in the long run". And if you are maintaining an overly complicated system, you can't un-complicate it. The old saying "you can't un-ring a bell" applies here.
    – user7519
    Jun 13, 2011 at 19:13

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.

  • 1
    +1, very good answer. I will carefully apply (keeping Mark Twain's, "There are three kinds of lies: lies, damned lies and statistics." in mind)
    – CMR
    Jun 13, 2011 at 17:56
  • @CMR -- Use analysis wisely, disasters happen when you ignore the results of your analysis, but they can also occur when you follow your results blindly :-)
    – Jay Elston
    Jun 14, 2011 at 3:13

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.

  • +1, agree. Your quote, Nice try, but that will not be feasible because of X and Y is dead on; I was looking for the X and Ys you have used for convincing, or have found convincing.
    – CMR
    Jun 13, 2011 at 17:54
  • 1
    The X and Ys should be varied based on the problem at hand. The X and Ys should never be "I've done this a million times". That is an obvious logical fallacy. An example of a good reason would be "No, we should not create our own XML database, because it will be drastically slower and less maintanable than a typical relational DB". Basically just show them that you have reasons for what you do, not blind faith in black magic engineering principles. Jun 13, 2011 at 18:57
  • As a caveat, sometimes the seniors are dinosaurs who don't understand any semblance of proper software engineering and write the kind of code that appears on TheDailyWTF because they either A) Think they're super-clever or B) Don't know any better and never cared to learn. These are the ones you need to be wary of because their design decisions are based on "I've always done it this way" and not actual reason. Jun 13, 2011 at 20:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.