It seems that even that developer tools has become more solid and robust, writing good code has become a challenge. Even that tools are more powerful, quality of code haven’t got better. I come up with two important factors, there is less time and the projects are more complex. Because tools we use today are more powerful it is easier to write more complex code, but having no time to plan and without looking back decreases code quality and increases bugs and maintenance. It is not that we didn’t write complex code before. It is that we write more complex code.

My question is the following: Considering we have more powerful language and tools.

  • Why is writing good code more difficult?
  • Do factors, time and complexity contribute to this?
  • Are methodologies not practiced correctly?

The type of project I consider is enterprise application with large complexity and business logic. The definition of “good code” is individual please don’t get stuck in the interpretation of “good code”.

14 Answers 14


As it was stated by DeMarco and Lister in Peopleware some 20ish years ago, the vast majority of failed software projects fail not due to technical challenges, but sociological problems. This hasn't changed in the past decades, no matter how much our tools have improved.

Mismanagement, unrealistic expectations, failing to get the right people for the job, and/or not letting them do their job, consequently failing to keep them; workplaces and tools which are not suitable for SW development work; unhandled personal conflicts; politics; these are just a few of the typical problems which may make a project doomed from the start.

Why writing good code is harder?

I am not quite convinced it is really harder to write good code now than it was decades ago. In fact, compared to machine code or assembly, everything we have now in the mainstream is way easier to handle. Just we may need to produce more of it.

Is it only because of the mention factors, time and complexity?

Yes, the achievable complexity has certainly increased (and continues to increase) as the power of our tools increases. In other words, we keep pushing the boundaries. Which to me translates so that it is equally hard to solve today's greatest challenges as it was 30 years ago to solve that day's greatest challenges.

OTOH since the field has grown so enormously, there are way more "small" or "known" problems now than there was 30 years ago. These problems are technically (should) not (be) a challenge anymore, but... here enters the above maxim :-(

Also the number of programmers have since grown enormously. And at least my personal perception is that the average level of experience and knowledge has declined, simply because there are far more juniors arriving continuously to the field than there are seniors who could educate them.

Is it that methodologies are not practiced correctly?

IMHO certainly not. DeMarco and Lister have some harsh words about big-M Methodologies. They say that no Methodology can make a project succeed - only the people in the team can. OTOH the small-m methodologies they praise are quite close to what we now know as "agile", which is spreading widely (IMHO for a good reason). Not to mention such good practices as unit testing and refactoring, which just 10 years ago weren't widely known, and nowadays even many graduates know these.

  • 3
    Not to be a grammar Nazi or anything but 'irrealistic' (In the second paragraph) is not a word. I think you mean 'unrealistic'.
    – user7007
    Commented Jan 27, 2011 at 23:35
  • I can only support the "Junior" issue. I am one of them and I certainly wish I had had a mentor to help me out. It's thankful that Internet is there today, and Amazon and SO help, but still... Commented Jan 28, 2011 at 18:34
  • 1
    +1: Also of note, because of the rapid change and growth in tools/technologies/methodologies, to a certain extent we're all juniors at least a couple of times a year. Experience just allows some vets to get up to speed more quickly than some jrs. Commented Apr 30, 2011 at 18:59
  • I refuse to take this question seriously unless we have no formal rules to separate beautiful code from ugly one.
    – shabunc
    Commented Jul 6, 2012 at 8:54

Issues related to coding under unrealistic deadlines and dealing with technical debt have been known since Weinberg '71 and also Brooks '72. The literature becomes hard to dig up online prior to that, but I'm fairly sure there are old CDC, IBM, and NASA reports saying the same thing.

  • 1
    + For "technical debt" and references. Commented Jan 27, 2011 at 20:20

I think we all have our own ideas and thresholds for "Good Code". However, there are a number of issues that all contribute:

  • Misapplication of "get it working then improve it" to mean we leave dead code and 10 different variants of the same method where each is used only once in the code base. This stuff never seems to be cleaned up.
  • Lack of time and budget. Client wants 100 new features in 3 months, some of them non-trivial, and they don't want to spend any money on stuff they can't directly see.
  • Lack of caring. Let's face it, some developers care about the way the code looks and behaves more than others. See the first bullet point for an example.
  • We really don't know how to create "good code". My concept of good code is continually evolving. What I thought was good a decade ago isn't so good any more.
  • "Good code" is a value judgement. Other than "it works", and there's no known bugs, any other criteria for good code is essentially a matter of opinion.

In the end, I think it is best to pursue better than it is to pursue "good" or "best". If we saw the best code out there, would we recognize it as such?

  • 1
    +1 Good point. By "good code" I didn't refer to perfect code. Perfect code doesn’t exist. “good code” is a code that don’t give you headache, it’s for example well thought. Commented Jan 27, 2011 at 20:42
  • 1
    Excellent point about "good code" being a moving target. However, I disagree with it being just a value judgement. I believe that clean code is easier to unit test, extend and maintain than messy code, thus is measureably cheaper in the long run. Of course, since we don't typically run double blind tests with control groups in real SW projects ;-), there is only anecdotal evidence to this, no hard scientific proof. Commented Jan 27, 2011 at 22:22
  • It looks like both of our current definitions of "good code" happen to agree. However, I've seen some rather stellar examples of good API design that made my life a lot easier--but the library didn't have unit tests. That doesn't mean it wasn't tested, just there wasn't anything to automate the testing. I'm leaving room for that. Commented Jan 27, 2011 at 22:46

Why writing good code is harder?

Because software is increasingly being build on top of abstraction layers. Each new technology that claims to make development easier and faster just adds one more level of complexity that a developer needs to understand. Now, these abstraction can have huge benefit to productivity, but if you don't understand what they are attempting to hide then it makes the software more susceptible to bugs and poor quality.

  • +1 Very good point, new tools increases productivity which may lead to more complexity. Commented Jan 27, 2011 at 20:30
  • 1
    +1. Also known as the "Law of Leaky Abstractions". :) Commented Jan 28, 2011 at 1:39

Is good code impossible in modern software development?

Indeed, it is not possible. But not for any of the reason's you've already heard.

The scope of the vast majority of the projects is well beyond the capacity of a human brain. Which is why people have come up with the idea of abstraction, that is keep hiding details and climb higher the abstraction tree until the density of branches (amount of information to handle) diminishes to an acceptable rate.

We've done that, we solved the complexity problem, but that hasn't removed the larger problem we had before.

It is still too complex for us to handle.

In order to create a high quality solution we need to be able to simultaneously see and understand everything at the same time, that is all the modules at a large and all little implementation details. All at once to see discrepancies, see each piece of code in the context of all possible scenarios and optimize the entire code base at the same time.

We won't ever be able to do that.

And if we can't we'll never produce quality code.

Managers will see the smattering of modules but won't know internal issues and limitations per module.

Module programmers will know local limitations but won't be able to optimize it in the context of a bigger picture.

There is no way to communicate understanding between managers and programmers (and even between programmers). And even if there were, the capacity of the human brain couldn't handle that.

There is little we can do except keep trying (a futile exercise). Let's just keep code more or less operational and enjoy the life.

  • I like this answer, if only it weren’t written in such a pessimistic, fatalist tone...
    – Timwi
    Commented Jan 28, 2011 at 3:59
  • 1
    @Timwi: Not pessimistic really. Was supposed to bring you a relief of burden. :)
    – user8685
    Commented Jan 28, 2011 at 12:09

I deny the premise of your question. It is easier than ever to write good code, and because of that we're tackling problems far harder that we've tackled before.

I don't want to pick on any particular vendor, but compare Windows 1.0 to Windows 7. The latter contains thousands of times more code, but the mean time between crashes has increased a hundredfold. We've been supposed to be able to embed an Excel spreadsheet in a Word document since Windows 3.1, but these days it actually more or less works.

Without wishing to fall into "You kids these days with your duck typing and VM" sentimentality, I would suggest that you have no idea how hard it was to write good code back in the 80s: TINY, SMALL, and HUGE memory models, overlays, non-rentrant OS calls (shudder). Good riddance to all of that.

  • Hate to go off-topic, but personally I would argue that Windows 1.0 to 3.11 were actually very stable, owing presumably to their lack of complexity. The crashiest versions of Windows were 95, 98 and ME. Of course, which versions were “good” in other ways is a different matter.
    – Timwi
    Commented Jan 28, 2011 at 3:56
  • What about coding on minicomputers or mainframes instead of low-power systems? The issues you reference are related to the Intel 8086 model... Commented Jan 28, 2011 at 17:11
  • @Paul, the 8086 problems were the ones I was most involved with, so they loom large in my mind. However the tools for writing software even on mainframes were amazingly crude by modern standards. The editors were generally closer to edlin than they were to emacs. As late as 1982 I was using NUROS (Nebraska University Remote Operating System) on IBM hardware. Jobs were programmed and run using 'virtual' punch cards. And let us not forget the Y2K bugs, mostly engendered on big iron by perceived constraints on storage. Commented Jan 28, 2011 at 17:41

Modern applications are more complex than they were 20-30 years ago, because their environment is richer and more versatile.

It was typical for a DOS-program to sit in a tight loop waiting for the next keypress from the user, and then invoke the corresponding code, and go back to waiting for the next keypress.

Any modern application where you cannot use the mouse at ALL for anything, has a serious explanation problem. And the things can happen in any order, as it is perfectly possible for the user to type, click with the mouse and continue typing while RSS-feeds are being updated in the application showing the newest entries to the user as he types.

All these multi-tasking things are intrinsicly much more complex than when all you had to think about was the keys from the user. That makes it harder to write truly good code.

Hopefully when the researchers have figured out how we can make multi-tasking programs more usable seen from the developers point of view, this may easen up but for now we are stuck with everybody trying to do it good, but not quite knowing how to do it.

  • +1 "Modern applications are more complex than they were 20-30 years ago" Commented Feb 18, 2011 at 7:40

In fact, I think it has become easier to write good code, i.e. programs that work as expected and are maintainable, during the last decade. The available tools are better now, the libs are more mature and comprehensive, hardware has become much faster so we don't have to use optimization tricks.

So why don't we?

IMO the main reason is that we constantly look for ways and excuses to abuse things. Instead of going the old-fashioned, easy, probably boring way, like creating a Windows executable, we push the boundaries of the possible and look for ways to e.g. recreate something like PhotoShop as a web application. Why? Because we can. Or at least we think so.

  • 1
    I disagree with the implication that innovation should be avoided and old-fashioned technologies or methods should never be obsoleted. Might as well stop writing any programs then and just use what we’ve got...
    – Timwi
    Commented Jan 28, 2011 at 4:03
  • Timwi: I'm not arguing against innovation. It's just the reason that it seems so hard to write good code.
    – user281377
    Commented Jan 28, 2011 at 8:03

It seems to me that software has expanded to fill the available processor speed, memory, disk, and programmer time. One could assert that that's because the software accomplishes a lot more. Well, I'm sure it does accomplish a lot more, but not enough to justify the bloat.

I think there's an ancient law of science worth remembering:

Nature abhors a vacuum.

Francois Rabelas (French monk and satirist 1494-1553)


When was the last time ANYONE not writing an exploit or studying to do so goofed around with assembly(not counting kernel hackers and ASIC guys)? How many bugs have been discovered in C core libraries? Almost none and a few. All I'm saying is that people are capable of excellent code. Better tools and languages just make it less 'required' and more 'optional'. Not that I think we should all write really awful code, but when I think of complicated logical constructs...no one would have dreamed of writing something with hash arrays in assembly. There had to be a 'better' way to handle the logic instead of using a complicated construct. Even if the code is beautiful, sometimes the approach is not as elegant. I think it sort of addresses the problem you mentioned. Good code is not always just organised, sometimes the approach to logic is even more beautiful.

  • Embedded system guys write a decent amount of assembly. Commented Jan 28, 2011 at 17:12
  • @Paul Nathan True Commented Jan 28, 2011 at 18:26

I think it is because better tools, and faster more responsive computers mean we expect to get much more final product complexity perunit time than we did a few years (or few decades) back. So the complexity of the apps keeps increasing, and our assumptions about what a reasonable level of productivity is keeps growing.

Where I work, developers are always in a hurry (because there are always more things that customers would want then they have time for). So lots of code blocks get copied with minimal editing,and without the effort made to really understand them. And of course errors get made. I just saw a bug get fixed, where a developer had copied some code I had optimized, without realizing that the assumptions that made the optimization valid weren't true where he was putting it.

This all comes down to expectations, both internal (our own expectations), and of our organizations. We try to do as much as possible in as short a time as possible. And errors inevitably result.

Also computer responsiveness encourages a quick fast edit, then a compile and test run. In the old old days (like 35years ago), turnaround was so slow, that I would print out code (source was punch cards then), and do a manual stepthrough of the code before submitting my deck. Now, we simply edit compile and execute. So a lot of bugs we would have spotted, via methodical code walkthrough, we now count on the compiler and/or the unit tests suite to catch instead.

  • Sounds like a young company which has not yet learned that the cheapest is doing it right the first time...
    – user1249
    Commented Jan 28, 2011 at 1:24
  • Thorbjorn: Amazingly it has been around for almost three decades. And its actually doing quite well. Of course there are business models that are very responsive to customer requests (us), and some that are very quality oriented. Its really hard to be both. Commented Feb 15, 2011 at 21:42

How have people gotten worse at producing good code?

If you take .NET and a language like C#, for example (and I realise it's not the only platform/language), I'd argue that coding well has become far, far easier due to the automation of many things within the Visual Studio environment.

If anything, the simply fact that we now have very sophisticated IDE's capable of guiding us through the coding and development process is making "good code" easier to achieve.

Programmers can now focus on actually producing good structure instead of spending so much time just typing brackets and braces and new lines and remembering method calls and class names.

My two cents.


Yes, we as an industry aren't practicing what is known to be good methodolgies. Reference: Steve McConnell's Construx Software Software Development's Low Hanging Fruit.


quality of code haven’t got better

please don’t get stuck in the interpretation of “good code”

Great logical tautology.

Code doesn't get better because people keep moving the definition of "good".

If you can' discuss "good code", then you can't compare and you really can't decide if it's "a challenge" or not.

  • For me "good code" is such that it decreases number of bugs. Now that can be accomplished in many ways. Commented Jan 27, 2011 at 20:34
  • @Amir Rezaei: "The definition of “good code” is individual". "'good code' is such that it decreases number of bugs" Please pick just one definition and update your question to include just one definition.
    – S.Lott
    Commented Jan 27, 2011 at 20:36
  • Well "'good code' is such that it decreases number of bugs" is my personal idea of "good code". I think everyone knows when project needs clean up or not. Commented Jan 27, 2011 at 20:45
  • @Amir Rezaei: This is my point. If you can't (or won't) define "good" in the question, then we can't compare. You can claim number of bugs are the same. Some else can claim that cost of bugs goes down. Another can claim that business risk due to planning for bugs goes up. Without a single definition of "good" we can all talk about different things. Please update the question.
    – S.Lott
    Commented Jan 27, 2011 at 20:57
  • Good Code: it compiled, passed tests, received user approval and was put into production. Just hope nobody wants to change it.
    – JeffO
    Commented Jan 27, 2011 at 21:25

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