Is good code impossible in modern software development? [closed]

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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)

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.