When coding software, should the architecture always be best practices or practical practices in regards to the application being built?

If I am building a two page web application that might live 5 years and have 2 enhancements over that 5 years, should I code in dependency injection, design patterns, model-view-controller with view models, etc

  • 53
    Over-engineering is not a best practice.
    – 5gon12eder
    Jun 14, 2016 at 19:23
  • 18
    There is no single 'best practices' that applies for all softwares in all situations. You'll have to evaluate what gives you the best payoff for the cost that applies to your specific situation. Jun 14, 2016 at 19:23
  • 10
    Be a pragmatic programmer. This should lead you down the path of least resistance.
    – Jon Raynor
    Jun 14, 2016 at 19:58
  • 3
    Can you provide a definition for best practice? Many answers seem to have this confused with some sort of literal interpretation they've created.
    – JeffO
    Jun 14, 2016 at 20:20
  • 5
    It's best practice to always use best practices.
    – Goose
    Jun 14, 2016 at 20:41

11 Answers 11


Should coding best practices always be used

Always? No, that's silly.

Best practices are guidelines. For most people, for most situations, if implemented with some finesse, they will yield the best results. They're where you start when considering solutions. But there will be places where best practices can and should be ignored, because there are better solutions.

The problem is that humans can't see into the future. And beginners (and a bunch of non-beginners) inevitably think that they are in that special scenario where the rules do not apply to them. When in doubt, use the best practices. Years of debate and experience across tons of engineers smarter than you or me have found them to produce consistently good results. But none (or almost none) of them know your particular problem as well as you do. Occasionally you'll run into exceptional cases where the rules can be bent.

  • 12
    ... But, define "best practice."
    – svidgen
    Jun 14, 2016 at 20:39
  • 4
    I think it's more common for beginners to want to do things "right," and blindly follow some best practices (e.g. software patterns) without really understanding why they exist or how to use them. Perhaps that's the second stage of enlightenment, the first stage being "I don't know what I'm doing." Jun 14, 2016 at 21:18
  • 19
    @RobertHarvey - first you learn what to do, then you learn why you do it, then you learn why you don't
    – HorusKol
    Jun 15, 2016 at 0:13
  • 1
    @HorusKol that might be one of the more profound things I've ever read. Jun 15, 2016 at 1:53
  • +1 for "humans can't see into the future" Jun 15, 2016 at 11:01

Yes. That is self-evident. Why would you not do what is best?

That's not the issue though. The hard part is finding out what IS the best practice, because in order to answer that you need to know exactly what requirements you have and how the project is likely to evolve over the years, and that is fiendishly hard.

One good rule of thumb however: It is NOT best practice, ever, to take the names of a bunch of design patterns and just jam them together without thinking.

Other than that, your question really cannot be answered. Figuring out exactly what "best practice" is for a given situation is what being a software engineer is all about. You're gonna have to narrow it down to get better answers.

  • 6
    Your answer escaped a downvote from me only because of your third paragraph. Jun 14, 2016 at 20:01
  • 4
    I'll throw an upvote for the third, but only because it's a best practice to do so. <Grin&Duck>
    – Blrfl
    Jun 14, 2016 at 20:12
  • 5
    My upvote applies to all four paragraphs equally. Jun 15, 2016 at 4:14
  • 4
    "best practices" is an idiomatic expression in the English discussion of software engineering, and it means something different from what this answer interprets it to mean, which is something like "the best possible solution to a given problem". So for example, "use source control" is described as a "best practice" regardless of whether or not there exists some problem for which source control is not part of the solution, i.e. regardless of whether or not it really is always best. This may be an appalling abuse of language, but it's what we're stuck with. Jun 15, 2016 at 8:43
  • 1
    @SteveJessop I am aware of this. However, there are many "best practices", and sometimes they conflict. The key is context and scope. There is always something that makes your situation special. Only by realizing exactly what your requirements are and what your constraints are can you identify which "best practice" is most applicable to your situation. A super contrived example: Using source control is best practice UNLESS someone is threatening to blow up the earth if you use source control. That would be additional context that changes what would be considered best practice.
    – sara
    Jun 15, 2016 at 8:56

The best practice is the one that most effectively fulfills your software's functional and non-functional requirements for features, maintainability, performance, etc. If that practice happens to align with some "industry standard," that's awesome. But if it doesn't, pragmatism wins.

Where I currently work, we're building a new web UI for our product from scratch. It will not be RESTful in any way; it uses POST exclusively. It's not multi-tier, doesn't use any microservices, and doesn't use a NoSQL database. It doesn't have any sort of architecture like Enterprise Java.

In other words, it's not hip at all.

But it does incorporate a state-of-the art HTML5 framework that features Angular-like databinding, automatic scaling to different device types like mobile and desktop, integration with Telerik's Kendo UI to do all of the heavy lifting, and a fully encrypted and secured data channel.

Best of all, it will be done in 30 days, a feat that would take an army of Java developers in an Enterprise architecture a year to achieve. The code is ES6/Typescript; it's some of the cleanest code I've ever seen.

  • I think your answer illustrates the point I was trying to make in mine ... At least I think so. +1 ... even though I'm still VTCing this question for lack of detail!
    – svidgen
    Jun 14, 2016 at 20:43
  • Sounds like my kind of project! Getting very tired of the fashions appear in development.
    – Matt Lacey
    Jun 15, 2016 at 7:14
  • RE Telerik: a word of warning on some of their widgets, the DateTimePicker is awful when used in conjuction with Angular if you want to modify the dates from Angular side at all.
    – Dan
    Jun 15, 2016 at 8:40
  • @DanPantry: I'll keep that in mind. Jun 15, 2016 at 19:44

No. Best practices are things that are generally considered to be the best thing to do 99% of the time, but that doesn't mean they always apply to every situation.

As a developer your job is to know and use those best practices, but also know when it's safe to cast them aside.

This isn't supposed to be self-promotion, but I recently wrote a blog post related to my work on the Salesforce.com platform that detailed one of these occasions. One of the golden rules there is "Never do a query inside of a loop", but recently, for the first time in 7 years of working on the platform I had a perfectly valid reason not to abide by that rule.

The gist is that the platform has limits on the number of queries you can perform in a given execution context, but in this case I had to query inside a loop to avoid running out of heap space and knew I'd be well within the query limit.

So it's rare, but there are times when best practices are not relevant to a scenario, so if they don't fit, don't force them.


I assume by "best practices" you mean some list of rules that someone wrote in a book. For of course if you mean the phrase literally, then of course you should always write the best code you can.

Need I point out that there is not a single, universally-accepted set of "best practices"? For any rule promoted by one expert, you can almost always find another expert with equal credentials who says something different.

But to the point: Short answer: usually, but not always.

Every field has its "best practices" and "textbook solutions". These represent the accumulated experience and wisdom of many, many people over many, many years, and should not be ignored. BUT! There are always special circumstances, fringe cases, etc. The truly capable person in any field knows when to follow the rules and when to break them.

I'd say in general: Start out by following the textbook rules. When following the textbook rules leads to trouble -- unnecessary complexity, poor performance, whatever -- then consider whether breaking this one rule this one time might not be a better idea.

If you ignore the rules and go wherever your whim of the moment leads you, your code will likely be a jumbled mess. No matter how smart you are, you are not the first programmer in the world. It makes sense to learn from the experience of others. In our daily life, this is why we have parents and teachers and preachers: so we don't have to repeat every stupid mistake ourselves in order to learn that it is a stupid mistake to make.

But if you slavishly follow a list of rules from some book 100% of the time, you will often find yourself hammering a square peg into a round hole. The people who wrote the rulebook may not have come across a case quite like yours. And even if they have, if it's rare enough they may have ignored it. A rule that works 80% of the time is an excellent rule -- as long as you understand that it works 80% of the time and not 100% of the time.

I wrote a book on database design that includes many rules that I advise database designers to follow. (I'll refrain from giving the title so I don't look like I'm shamelessly slipping in self-promotion.) I certainly encourage anyone who wants to design a database to read a book like mine and learn all they can from it. But OF COURSE there are times when you should break the rules I list.

I once wrote a programming standards document for a team of developers that I led at the time. And the last rule went something like this: "If you have a good reason to break one of the above rules, then go ahead, BUT you must include a comment in your code explaining why you broke the rule. If you can't come up with a good reason, then follow the rule. If writing the comment is more trouble than following the rule, then follow the rule." We had only a handful of times that someone found breaking a rule worth the trouble of having to explain why.


By best practices, I'm assuming you mean "informal rules that the software development community has learned over time which can help improve the quality of software" and not some sort of literal best way of doing a specific task.

Yes, until you have a reason not to. It should be a good reason that you've given serious consideration and applied to the circumstances and limitations of the task at hand. That means you fully understand the practice and are able to apply it. Let's not get into this notion that if you don't understand it, then it must not be the best kind of thinking. See the definition.

You're not always going to do what is best. When the boss tells you to, "Ship this piece of crap or you're fired!" You'll ship it and probably go look for another job, but you'll still ship it. Sometimes you'll find yourself doing something that is good enough. Of course, you don't want to make a habit of this, but sometimes you have to get the wagons rolling and you can't worry about the horses being blind.


Some things are important, some aren't.

You should tailor your choice of language and style to the problem at hand.

For instance, a "Best Practice" for exception handling might be to always catch exceptions and log them, but when creating a unit test the best practice is often to let them throw out so the unit testing framework can report them correctly.

On the other hand, consider the "DRY" rule. Striving for code that doesn't repeat itself is always good, not only because of the obvious reasons, but also because the more you code that way the better a coder you become--it is a great way to flex your coding/thinking skills instead of your typing and copy/paste skills, and in the long run you'll generally feel better revisiting your code (even when you expected it to be throw-away code) if you followed some sensible rules.

In summary, be flexible but don't just code unreadable junk because you think it's throw-away code.


I'll try to view from a different perspective.

Today's modern frameworks make it very easy to setup a basic project with mvc, dependency injection, layered architecture etc. (spring boot lover here). I'd say start with a generated base and use the tools provided for you, until you bump into something that requires a handmade solution. Then you may cut corners from those best practices.

It's not harder to use something like Spring Boot for 2 page web app, then rolling your own servlets, jdbc queries and other things.


In my experience there is only one best practice that I consider to be mandatory:

Keep It Simple, Stupid (KISS)

In other words: Whatever tools, APIs, architectures, etc you choose - if you keep it simple, it's more likely to be easy to work on the future, have less bugs, be fast, memory efficient and everything else you might desire.

All those other things people talk about: Principles, patterns, practices, etc - I regard as being a pallet of tools I can choose from, selecting those that best suite the project I'm working on. They all provide techniques and ideas for solving problems. The trick is to figure out if you have those problems in the first place.


The best "Best Practices" always contain a section that you should use your intelligence and experience to identify when the items in the manual are inappropriate. They may also contain a section on reviewing, approving, and documenting such exceptions and making them part of the "best" practices.


When coding software, should the architecture always be best practices or practical practices in regards to the application being built?

In Theory, yes.

In the Real World, [still] yes, as long as you can afford to do so.

Which, of course, means, "No".

Time and money pressures will always try to push you down the road of a "quick and dirty" solution, because it delivers "better" Value to the client. How that is implemented is of no interest to the client or their accountants. If you can do a job [badly] in two days or perfectly in three months, which do you think they're going to ask you for?

The gap between the two - best practice and what you have to "get away" with - is called "Technical Debt"; it's perfectly acceptable, as long as you have a plan to "repay" it, i.e. to go back and improve things later. Again, not something you always (ever?) get the budget for.

One tactic is to release an early, Beta, version with the "quick" fix in it, but ensure that the necessary architectural improvements are prioritised before the "full" release. Again, not something you always (ever?) get to do.

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