Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am a developer who works for an in-house information communications technology (ICT) department.

I am usually quite critical when looking over code that I have not written as I find time and time again that it does not follow principles like SOLID (single responsibility etc). I used to assume that it was because I worked in an in-house ICT department rather than an outsourced ICT service. However, I am now trying to integrate an internally developed app with a few third party apps developed by large software vendors. However, again the code does not seem to be very well written e.g. there are no interfaces and every method is public.

I see it time and time again were developers create a bunch of classes and that's it (i.e., everything related to Sales goes in the Sales class, etc.)

I don't want to sound like I am whining; I just wondered whether other developers see design principles as important. I wonder if I am too narrow minded.

share|improve this question

closed as not constructive by GrandmasterB, Glenn Nelson, MichaelT, Dynamic, Mason Wheeler Feb 22 '13 at 21:14

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Remember that third party apps developed by large software vendors you find not so good may have been written fifteen years ago, and had to carry all the bad stuff in order to be backwards compatible while evolving and implementing new features. – MainMa Feb 22 '13 at 19:12
There is, unfortunately, a great deal of pretty lousy code out there, much of which is being sold for real money. – Blrfl Feb 22 '13 at 21:04

In short, yes. I don't think anyone will disagree that design principles are good.

That said, what you are seeing is simply that they are not well known. There are a great many engineers out there, and a large portion of them stop studying things like that after school. Add on top of that the fact that there is no magical GoF book that the whole world responded to for the principles. On top of that "design principles" sounds so similar to "design patterns" that when people do hear about them, more often than not they just hear the more common "design patterns", and look no further into principles.

They are good, yes, they are just very uncommonly known due to a variety of unfortunate mitagating factors halting their spread. Keep on keeping on, and mentor people in their practice as you do your job, your fellow engineers will thank you for it.

share|improve this answer

These are some reasons why design principles aren't used so widely:

  1. the code should be ready in tight deadlines, which are met by lowering the code quality;
  2. it is assumed that the developers won't need to come back to the code again, so developers don't spend much time to produce good code;
  3. the quality of code isn't given a high priority;
  4. design principles are relatively difficult to understand and even more difficult to apply;
  5. the advantages of design principles aren't so evident. They become visible mostly when writing unit tests, refactoring the old code, reusing and extending it;

I think the biggest problem is that it is often assumed that producing good code takes more time than just making something work. And design principles IMO are in the "major league", and it takes time and experience to start using them.

share|improve this answer
A lot of people simply aren't very good at what they do; but +1 for pointing out several reasons why even good programmers write poor code sometimes. – Carson63000 Feb 22 '13 at 19:56

Design principles are important, but there are few absolutes in this industry. Applying them in the right context is important. I heard a talk about Domain Driven Design. A key point was stressed that you don't apply this to all projects. It is best left to very complicated problems and knowing up front that it is difficult and requires a lengthy time commitment by everyone. A developer may find the ideal candidate for this approach only to be turned-down by other decision makers.

Many projects start small and for many reasons continue to grow. It's a lot easier to recognize patterns at this point that may not have been needed at the beginning and project demands prevented their implementation.

Vince Lombardi said, "Fatigue makes cowards of us all." Time pressures, team limitations, and not knowing all the requirements at the beginning of a project can prevent the usage of good design principles. That doesn't excuse every project that start out as a big ball of mud. Good programmers understand them, but the great ones make sure they are implemented even in the most dire of circumstances. Maybe because they have seen the consequences if you don't?

There's a reason it's difficult to find good programmers. Many have not been exposed to the best practices and few are able to implement them by only reading a book.

share|improve this answer
+1. I believe honesty is one of the general design principles. – SChepurin Feb 22 '13 at 19:59

In my experience the vast majority of developers feel design principles are important, and make every effort to incorporate them into their code. However, there are several reasons you can't tell this from looking at a large code base:

  • Legacy code bases aren't designed. They evolve. It's easy to look at code from fresh eyes and say "I wouldn't design it like that." What you don't see is the entire history of compromises that led the code to that point. Hindsight is 20/20.
  • It's much easier to write bad code than to read it. People code down at a microscopic level of detail. At that level, it's easy to miss the forest for the trees. That's why good code almost always requires a refactoring step before you check it in. If people are rushed, they may forego that step.
  • Poor design decisions aren't usually obvious until they're difficult to change. The longer the design has been in the code base, the more code depends on the poorly designed code, and the harder it is to change, no matter how much you want to. The other day a change I was making was a lot more difficult than I anticipated. When I investigated the design to determine why, I realized I should have used composition instead of inheritance for a few dozen classes, but that decision was made such a long time ago that it was too much work to remove "while I was at it." I had to just deal with it at the moment to finish my feature, then correct the design problem a few days later.
share|improve this answer

Good design principles are extremely important- that's what makes them "good" rather than "mediocre" or "perfectionist". The developers of that code must simply not have been very experienced when it was written.

share|improve this answer
What do you consider Good design principles ? – Jimmy Hoffa Feb 22 '13 at 19:10

Two questions:

  1. Is the code your team has developed difficult to maintain because it does not follow SOLID principles?
  2. Are you having difficulty integrating with the third-party apps because of this lack of following good principles?

If the answer to either of these questions is yes, then I'd say you know the answer to your own question.

Still, you've got to look at the priorities of your company's management--if they are probably balancing the value of fast delivery of the initial solution with the costs of quality and maintenance. On one hand, being late to market may mean you're never in the market, on the other, a crappy product will cost you a lot more in the long run.

So, I'd say design principles are very important, but they aren't the only thing.

share|improve this answer

As everyone has said, yes, design principles are extremely beneficial. I don't think it's always that design principles aren't known, so much as that code rot sets in and forces kludge on top of kludge to deal with it. The natural remedy would be refactoring, but often times managers will break out in hives at the thought of developer hours spent on work that doesn't create immediate business value.

So as code bases age, the Broken Window theory shows its ugly head, and any once-well-intentioned-code becomes lost in the fray.

share|improve this answer

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