I don't know that it takes that long to build software.
That is, the expectation that software be immediately available because you can vaguely imagine what it would do for you is strange.
Why does it take so long to build software? (2020)
71–80 of 180 posts
Re: Why does it take so long to build software? (2020)
#72It's because most software developers add negative value. Most not them aren't investing in learning at all and are just playing around and understanding things on the surface level. I'm fairly certain it takes much more learning and effort to keep up to date as an accountant than a software engineer. I've been getting into elixir and was very sad to realise that a lot of the best practices have been enshrined into t…
"it takes much more learning and effort to keep up to date as an accountant than a software engineer" you are wrong in many levels.... accounting is a field that moves slowly and it is highly regulated Software is still in the wild wild west phase, and it catches and loses trends all the time. We are currently using languages and platforms that didn't exist at all 10-12 years ago, yet, in 10 years whatever you are do…
But experience with one language tranfers quite well to a new one. I also see a deep problem from the business side, that a programmer is easily replaceable ot that just by throwing more (mediocre) people at the problem will help solve it faster, or even the existence of rock-star developers.
Building software is slow, because essential complexity. We are writing programs that no one person can hold in their heads. And based on the average CRUD app, it might not be trivial (even though they are already increasingly complex), but more complex applications really can take multiple years/decades to create. And it is a bit sad that there is little focus on reuse, even though that is the only silver-bullet out there. No language, no tool; but (high-quality) libraries.
Re: Why does it take so long to build software? (2020)
#73A lot of accidental complexity arises from adding more people to the mix. There is the communication overhead to deal with. Even when things go well this consumes time. When it doesn't: more time. Then there's of course the constant arguing and bickering over what is best; more people means more opinions on this. And of course the more people you have the more complexity gets introduced. Conway's law is a thing.
The benchmark for me is what I think I can pull off in a few days vs. what I would build with a whole team in a few months. You can build a lot in a weekend. But not not with a whole team around you questioning every move. So, when I need quick results, I give the right people a lot of freedom and not too many distractions and see what happens.
I'm building a new webapp for a startup with a few people since three weeks. We're launching with customers next month. That involves a lot of pragmatic decision making and taking on a few risks. Most of the hard choices were made in the first week and at this point the app is starting to look alright.
Here's what we did not do: we had no designers involved. We also had no lengthy meetings about what features we were going to have. We're patching up our existing backend and adding some new features to it.
Otherwise, it's an emergency rebuild of an app that just wasn't good enough (wrong mobile platform, developer is out of the picture, and it's a lot of technical debt and stability issues). I took the decision in December and gave our inexperienced frontend person some guidance to investigate the technologies I picked for him. By December we had a clear idea that this was doable. January we started doing this. That's 3 weeks ago. By now it's largely done. We're adding a few missing features and then we have an MVP that will run on IOS, Android and the web.
If I had a few million, I could not do this any faster. But I'd be able to ship beautifully native apps six months later. If fast is a goal, keep your team lean.
Re: Why does it take so long to build software? (2020)
#74One aspect that is not mentioned is that we build software on top of an ever-increasing number of first-to-market, low-quality, building blocks. And by low-quality I mean "worse is better"/MVP/"everyone makes mistakes"/"leaky abstractions"/etc -- pick your favorite. As a result, we spend more and more time dealing with someone else's mistakes rather than making forward progress.
I dunno, there's a lot of really high quality stable software out there. It's not all crap. But as someone who has had the luxury of taking time to do things the Right Way let me tell you from firsthand experience: doing things the Right Way is incredibly hard in no small measure because figuring out what you actually want to do is incredibly hard. There have been many times when I thought I was building something fo…
You are right, not all is crap. But too many people are not aware how much is crap and are pretty naive about using libraries. I don't think it is an accident, that e.g. the Java universe has uncountable numbers of libraries and Java projects have unbelievable many dependencies and e.g. Lisp has a percived lack of libraries. There are many reasons for that, but also, that Lisp programmers tend to rely on libraries less.
Re: Why does it take so long to build software? (2020)
#75In an average replicate (FB, HN, Twitter) tutorial, students can see how with an amazing developer skills, someone creates the finished product from 15 minutes to 2 hours. But, when they try to do the same, it takes days, weeks or months.
And this also applies to an experienced developer; the reason is depth. (How deep to the rabbit hole do we want to go).
There are always hidden complexities, configuration, installations, validations, issues, known obstacles and unknown obstacles; there is time for meetings, negotiations, time for thinking, time for merely trying to come up with the best approach long before we start coding.
A good example from my early career was "just one field in the database", a client says "hey this will take you just 1 minute, why you are arguing with me about this", but that "one field" is so much intertwined that can affect half of the codebase. It means, going through all procedures, views, models, tests, validations, then there is an impact on historical data etc...
Also there is a huge difference between: spike, MVP, and finished product.
Re: Why does it take so long to build software? (2020)
#76Software takes a long time to build because it's always new. That is, software is trivially copy-able, so there is no reason to spend effort duplicating any software that already exists. (Legal reasons and "not-invented-here" syndrome notwithstanding.) This is a huge different from how the "real" world works, where almost all of the work involved in building, say, a car, is actually just the work of assembling identi…
If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does. The conclusion is that the tools to build software from a known specification to working code are sub-optimal.
I don’t want to sound smartass but building an identical clone of an existing application is very fast and often totally automated. That’s what your compiler chain does.
Re: Why does it take so long to build software? (2020)
#77Just think about building a simple saas website.
What do you need
A marketing page A dashboard set of elements A payment system A billing history, refund, change card, invoice system A token system A auth system A email system or integration with a email provider. A complaint system A admin dashboard A often custom database schema A analytics system and useage A log tracker A cloud infrastructure for hosting Rate limiting A api A event logging system A marketing blog
I have strayed too far.
My point is each one if these things is usually build from scratch. It takes a lot of time, then you have to wire everything together. In typical custom ways. If someone makes a off the shelf version typically the learning curve is greater than building a custom version.
I think software takes so log because each dev tries to rebuild the wheel. And often times the wheel does need to be rebuilt. But due to time issues things never get finished to the degree you planned and your custom code has been rewritten 10 times and each new feature take a logx longer to not break the old stuff.
Re: Why does it take so long to build software? (2020)
#78I wonder if part of this is because the commercial pressures aren't there, that there is so much money sloshing about the industry that we can get away with sloppy practices.
Re: Why does it take so long to build software? (2020)
#79One aspect that is not mentioned is that we build software on top of an ever-increasing number of first-to-market, low-quality, building blocks. And by low-quality I mean "worse is better"/MVP/"everyone makes mistakes"/"leaky abstractions"/etc -- pick your favorite. As a result, we spend more and more time dealing with someone else's mistakes rather than making forward progress.
I dunno, there's a lot of really high quality stable software out there. It's not all crap. But as someone who has had the luxury of taking time to do things the Right Way let me tell you from firsthand experience: doing things the Right Way is incredibly hard in no small measure because figuring out what you actually want to do is incredibly hard. There have been many times when I thought I was building something fo…
Wow, after your comment about having the luxury of taking time I wanted to find out how. I found your website in your bio. Very impressive and very cool to see even huge successes find the time to comment on HN.
Re: Why does it take so long to build software? (2020)
#80Earlier quoted context omitted.
If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does. The conclusion is that the tools to build software from a known specification to working code are sub-optimal.
> The conclusion is that the tools to build software from a known specification to working code are sub-optimal. That may be true, but I don't know that your example supports it. Cloning an app doesn't mean you had a specification for the app. The tools to build a known specification from an existing app are sub-optimal, as are the tools to build a known specification from scratch. I've only rarely in my career had t…
> The tools to build a known specification from an existing app are sub-optimal, as are the tools to build a known specification from scratch.
That actually reinforces my point ;-) All the steps in the toolchain could benefit from more agile interactions, allowing the programmer to spend less time fiddling with syntax errors and recalling which functions need to be applied in what order, and more time evaluating and fixing errors in the current logic as written. That would expose what the build program is doing and how it differs from the expected intent.
The online notebooks used in data analysis (Jupyter, Apache Zeppelin) are a step in the right direction; IMHO their approach of 'data is always readable besides the code processing it' makes for a better introspection infrastructure than the REPL loops of old.