I can see this as a valid question for a subset of problems. For example, the basic database CRUD applications that get built over and over.
The closest solutions I've seen were DabbleDB (acquired by Twitter and shuttered) and Quickbase (laudable, but the pricing model doesn't work for many).
To me, software projects take longer than i think because customers don't know what they actually need until there's a runnable version of what they want.
For context, I'm talking about the initial phase of a product's lifecycle, where you are changing the product definition roughly every couple days, the total codebase fits in one person's head, and you spend much more time writing code than reading it.
Systems like PHP + "SELECT * FROM database_table" or the MEAN stack, where you use the same data format for both backend storage and UI and intermingle logic with templates, are significantly faster for getting something workable on the screen that users can try out. I've done a complete MVP in 4 days with PHP; a roughly equivalent app in Django (which has some minimal model/view/database separation) took about 2-3 weeks. The fastest I could launch a feature in Google Search that touched both UI and indexing was roughly 6 months; as you'd expect, that has a very rigorous separation of front and back-ends.
Now, the PHP solution will quickly become unmaintainable - with the aforementioned 4 day project, I no longer wanted to touch the code after about 3 weeks. But this doesn't matter - it's 10 years later and the software is still serving users, and I long since moved on to bigger and better things. And that's my general point: what's "good" code is context-sensitive. Everybody wants to work on nicely-factored code where you can understand everything, but there is no business to pay you unless you first make something that people want, and oftentimes that takes hundreds of iterations (including many fresh starts where you throw everything away and rebuild from scratch) that are invisible to anyone collecting a paycheck.
It's a matter of motivation. I had project flushing in speed, with correct, tested code, happy clients and I also had other assignments, where a feature that that should take a week took a year.
That's insane about our field, the sheer variance in so many things we do.
The software is way too complex to gauge how long something will take. It’s also extremely risky to make a mistake in production. Projects slated for three months can take two years.
If you’re engineers are constantly hitting deadlines, probably it’s greenfield development or the problem space is simple
It doesn't take me days to get a Java web app up and running. It takes me minutes. In days, my Java web app is done.
I'm a senior engineer who codes for pleasure, so maybe I'm faster than average --- but if it's taking you days to get your libraries together and minor db changes touch every layer, you're doing something wrong.
3-6 months is barely enough time to figure out a reasonably complex codebase. That's ridiculously little time to "serve". Whoever came up with that duration has never run a complex software project.
Software projects are usually 90% done in 1% of total time taken. And if you just solve the problem with duct tape eg. a shell script, like piping stdin to a file, or contenteditable=true in HTML, you would have a very basic word program, and if you take that route you will probably have the essential features done over a weekend. But going from that to a full Office clone would take years. The real challenge in development though is to solve real problems, eg not make solutions looking for a problem, and not implement new features ( implementing only features that solve real problems).
Unfortunately I don't think nothing is more quick then developer time for money. Small projects can yield okay results but can also end up being time consuming.
software development process has improved a lot over years. Now it's not that hard to ship production ready application/feature in weeks rather than months or years. Product development teams are typically dedicated to one product at a time and their performance and to some extent their employment is measured on how much new software is shipped every sprint so they have to come up with something every 2 weeks.
The data will be apples and oranges. It won't tell you anything.
A typical CRUD back-end can be built in a day or two by a single dev, especially if s/he is not worrying about writing DRY, elegant code that is easy to maintain.
A serious back-end solving novel problems, dealing with high demand, or incorporating many asynchronous processes could easily take 5 devs a full 6 months to build.
It's a 20 year old codebase, so it's gotten so bad that we spend 2 weeks planning something that could take me 1 week to write in the current codebase or 1 day to write in a sane codebase, on a product that I could probably re-write from scratch in a month.
"It doesn't take very long to 'build' the software or the website (obvious 'large scale' projects like OSes excepted)."
A lot of assumptions have to be met for that to be true. It shouldn't take very long provided:
1. The programmers are very familiar with the tools.
2. The programmers are very familiar with all necessary 3rd party components.
3. The 3rd party components account for 99% of functionality.
4. The programmers have built that exact project before, preferably more than once.
I usually work in a best-case scenario for development: I'm building projects with limited scope, solo and with no other decision makers involved in the project. I'm also experienced enough to know how complex things will generally be from a high level standpoint. And I have never once met my own estimate for complexity and the amount of time something will take. Exactly 100% of the time silly, seemingly inconsequential things add up to an extra 30% or more.
It doesn't matter if you can write 1000 shippable lines of code in a day because tomorrow you'll spend most of your time hunting a bug in an external library. Suddenly your machine-like pace has been cut in half. This happens on every project I've worked on and I would assume all software projects.
I agree that poor planning adds to the amount of time needed. Of course it does. But there really is no "best case" scenario where you and a couple of buddies could hammer out Facebook in three weeks.
To know how long something takes you must have done it already.
And that's the problem with software, there are no equals. And there are always "surprises".
A car manufacturer knows how long it takes to build a car, because it does that thousands of times for a same model. Now, designing the car, that's a different issue. (And don't give me the BS enterprise "model" of architects throwing some UML from a high tower and "developers" filling the voids because that's the worse way you can build a software)
Ok, it's one thing to build a simple ACID application, another thing is to build something that "has never been tried before" .
I started back the days of CASE and RAD developing Windows apps against a database then eventually am middle tier. You could build something useful, stable, and production ready in a couple of days or weeks depending on the complexity.
I can see this as a valid question for a subset of problems. For example, the basic database CRUD applications that get built over and over.
The closest solutions I've seen were DabbleDB (acquired by Twitter and shuttered) and Quickbase (laudable, but the pricing model doesn't work for many).
reply