Why is coding so slow?

Question

Is it only me, or is coding getting slower and slower, until a product("a project") is finished?

This question came to me as I saw the "Write a program in 30 minutes":

I thought it is impossible to write a decent piece of code which runs smoothly.

As I am getting older I see on all projects, even simple ones a lot of additional work, to get them into a state where everybody can use them. So you need a lot of error-catching, UI-Design, even texts, so your app can communicate with endusers. Back in the old days(around 1985) it was possible to build something usable in some weeks, maybe months. Today You will spend at least a man-year for developing an robust application which performs a nontrivial task.

Of course, the complexity has increased, but I am just worried about the scaling of application complexity regarding to development time.

Answer 1

IMHO, your wrong.

High level languages have made rapid development possible. This has counterbalanced the rise in application complexity, so that it still takes a similar amount of time to develop a quality application.

Answer 2

coding had actually gotten much, much faster since 1985, thanks to vastly better tools, but now we demand more of our applications

Answer 3

I think you have to take into account that the "non-trivial tasks" are somewhat more non-trivial than they were 20 years ago.

With increasing complexity comes a vastly increased time needed to finish a product.

Looking at coding aids like coderush I think it would be extremely wrong to say that coding got slower during the years - the opposite is the case.

Answer 4

OK I see your point:

essentially you say, "you may need more resources, but it will be paid", however, if complexity will continue to increase, you have to have more developers on a project, this scales not very well in regards to management, payment etc.

If you think this to an end it means: Software projects will be more expensive and needs more people to accomplish a task. This also means each person will get less money

If you want to see a real live example, look into the games industry: projects grew from 1 person games in 80ies to 3-8 person games in 90ies today on an AAA-title are easily >100 people involved. With this amount of people you have more problems for each person inside (maybe except CEOs): less money, more work and responsibility

Is this the same for all software industry branches?

Answer 5

I disagree that it takes a whole person-year to develop a non-trivial application.

I can only quote directly from my own experience, but most of our applications take only 1-3 person-months. Admittedly, we have built ourselves a very high-level framework which does a lot of the work for us; and we do limit ourselves to web-based business process applications, which means there is lots we can reuse from one to the other.

I think by using the right tools, having smart people and doing things the right way, you can develop software faster than in the past. No Silver Bullet is a good essay, but if you re-read it (as I did recently) it doesn't say you can't get an order of magnitude productivity improvement overall - it just tells you not to expect it from a single change or a single new tool.

Answer 6

Because programming is really, really difficult?!

Answer 7

I think your question is well answered by Fred Brook's famous essay, No SIlver Bullet. You can get the essence of his argument from Wikipedia. The crux of the argument is that essential complexity, the problem the software is trying to solve, is why software is hard and slow. Accidental complexity is what new languages and IDEs solve.

I disagree with all the answers I've seen. Newer languages and improved tools only improve productivity a small amount. The only big jump in productivity I've seen in my career is going from assembler to C. Everything since then is a slight increment. And even with that leap, we haven't solved the essential complexity of what applications are doing.

I think people often confuse the increase in their personal productivity as they go from beginner to accomplished developer with a general increase in productivity. People often go from solving simple problems to being involved in every larger teams and applications, too, so they think applications are generally becoming more complex.

People were writing extremely complex applications in the 1950's, too. Most people don't know enough about the history of the industry to realize it.

Answer 8

In the industry today, we have "solved" a lot of the framework issues we used to struggle with. We've got no end of tools for desktop GUIs, web frameworks, database access, and communications plumbing. Take your pick. But the real problem lies in the complexity of the business problem you are trying to solve. No toolkit exists to solve that problem (thank god), nor will it ever. If it did, hypothetically speaking, then no company would have any real competitive advantage over another one. Sure you've got some software that solves a particular problem in common to most businesses (accounting packages, some ERP modules), but most of the toolkits are for specific technology issues and not business problems.

As for a minimum of 1 man year I think it obviously depends on what you're trying to build. The key difference today as opposed to the 80's when I started programming is that we can spend more time on the business issues and less time changing the software every single flipping time we needed to add support for yet another type of printer :-) Hence the business problems we are solving are getting bigger to fill that void.

Answer 9

The amount of time dedicated to realizing a abstraction from a real life situation (be it a video game forest, or a sales contract) is related to the amount of detail with which we want to replicate that real life object.

In the 80s, we made do with a minimum of abstraction to get the job done.

Nowadays, a AAA game title uses much more detailed abstractions (programming things like wind, weather, interactive blades of grass), and that requires dedication.

So, the greater the detail of the abstraction you're trying to replicate, the more time you need.

This doesn't account for wasteful details (rendering the boogers in your enemy's nose), and for tuning the accuracy of these abstractions (if a guerilla fart is traveling NW at 2 knots, and the wind is blowing SE 13 knots directions, which way should the grass near his ass blow?)

Answer 10

In 1985, the software users where scientist and the app environements fully under control.

Now you must build for somebody who don't need to know anything about the way it works and ensure it will run in an environment with thousand of variables aren't even related to the app purpose.

Thanks to modern tech, dev is faster. But needs have change, that's why it feels slower.

Writing a static web page and a 'simple' blog engine are just like building a hammer and a hammer factory.

Answer 11

Because you waste too much time on discussion on internet sites instead of actually coding?

Programmers are considered notoriously bad at estimating time to completion. It turns out though that we're not far off if we consider only the coding time -- the problem is all the other crap in our workdays, from useless meetings to, yes, goofing off on the internet.

Answer 12

This may sound cynical:

We as programmers must spend a lot of time trying to take extremely complex requirements written by analysts who have no idea what we actually "do for a living that takes so much time" and then proceed to attempt to mold those requirements into modules that fit within the unnecessary third-party libraries that we are required to used because some consultant who was hired by another consultant convinced upper-management that it was a good idea to spend a lot of money.

wow, that was a bit more harsh than I intended, and please pardon my grammar.

Answer 13

When my boss asks why development of 'feature A124#' took soooo long (and he doesn't do that much, I must admit, because he is also a good developer and we're working together for quite some time), my typical answer is: "Because we already solved all simple problems."

Demand has overtaken programming tools so to solve harder and harder problems we have to work more and more. That's why we need better tools.

Answer 14

Check out The law of leaking abstractions by Joel Spolsky

Ten years ago, we might have imagined that new programming paradigms would have made programming easier by now. Indeed, the abstractions we've created over the years do allow us to deal with new orders of complexity in software development that we didn't have to deal with ten or fifteen years ago, like GUI programming and network programming. And while these great tools, like modern OO forms-based languages, let us get a lot of work done incredibly quickly, suddenly one day we need to figure out a problem where the abstraction leaked, and it takes 2 weeks. And when you need to hire a programmer to do mostly VB programming, it's not good enough to hire a VB programmer, because they will get completely stuck in tar every time the VB abstraction leaks.

The Law of Leaky Abstractions is dragging us down.

Answer 15

Hi Peter,

I've felt it that way too. And for me I have to believe that nowadays we are writing more code because we want to make the development process fail-proof / maintainable with even more code. That's why we:

1. Separate UI from data processing and data storing (and each of these layers have added complexiety)
2. Use frameworks which alllow us to change the database without too much extra work,
3. Create automated tests and unit-test all the parts of a software
4. Implement patterns everywhere

What's more, nowadays we have even more ways of doing exactly the same thing - either by knowing better frameworks / libraries / components or by selecting the best algorithms - and making decisions like this take some time.

The time necessary to create / decide and execute all this stuff is quite big, but I want to believe that it is well spent when you are no longer required to start from zero when you can no longer maintain an application, for instance.