There is also incredible bureaucracy, such that attempting iterative agile development is almost certainly doomed.
One reason many Web apps are so sleek and fit is that the developers could code, release, judge, and repeat daily.
This is much harder to do with large entities, who a) will need to present Accounting with the One True Final Cost for pre-approval and budgeting, and b) will need to have Official Sign-Off on the Absolute Final Specs from some dozen department heads.
This is what happens to software development within large corporations. Developers are being managed by a bureaucracy that doesn't have a clue about software development.
Development in any corp today, even middle-sized ones, is a big red tape festival. You have a project divided in sprints that are divided in (often meaningless) tasks, then you have a completely bloated CI/CD system and then things get deployed to three or four environments where people pretend to test everything. Things that might be developed by a journeyman developer in five days take six weeks to be done by a team of eight developers.
The whole process today exists to support a big class of managerial people(including scrum masters, PO's and PM's) whose salary depends on not understanding that the process is completely broken.
(As someone who often works for smaller orgs) It doesn't HAVE to be that way. None of the smaller orgs I've worked for use those systems. Only the big techy ones with a lot of bureaucracies do. They pay better, but you do much less, and push around a lot of paperwork instead of code. There ARE alternatives. Your average small town non-IT company probably still needs developers here and there, and they won't have the resources for the overhead of Agile bullshit. You'll typically have the keys to the kingdom and have to make shit work with very limited resources and a tiny team, but it's a heck lot more fun.
I tried a big corpo job for a bit, ugh, never again.
I have seen all of these symptoms at numerous large companies. The backlog is years deep and the costs associated with engaging the professional programmers could be staggering. The truth is, not all solutions need anything more robust than what Office can provide.
You've seen the xkcd chart about automating and the cost/reward for varying numbers of repetitions per day? I think the concept that big businesses are behemoths stems from a fundamental understanding of what each type of business does each day.
As an arbitrary example, I think if we compare the number of employees onboarded vs the number of new applications shipped, small companies/startups and enterprises are polar opposites. My experience with startups is that you end up with a new web service for every 2-4 people (wholly anecdotal) you onboard as developers. For that kind of company, it makes sense to optimize shipping new web services; you do it a lot! For an Enterprise, you might onboard 100 developers just to maintain and develop existing systems. Writing new frameworks to make building apps easier doesn't make much sense; many of your developers are working on an existing system that would be expensive to port to a new framework. Meantime, your HR department is drowning trying to onboard 20 people a week.
Wasting money shipping this listing is fine; they did it once. This was released in 2013, and I wouldn't be terribly surprised to find out this, or some small bastardization of this, is still running as a production page for Prudence. The money they wasted, amortized over 6 years, is nothing compared to what I've seen startups waste in productivity while new hires wait for laptops, credentials, access, someone to explain some legacy crap that everyone had to deal with, etc.
The kinds of bills that some large company development environments end up running are surprisingly high, but those companies also think the opportunity cost of losing productivity on application team developers to also very high. That's how you find companies that decide to hire very expensive teams to, say, add types to a dynamic language, rewrite a standard library, invest in massive parallelism to run thousands of CPU hour integration tests in 15 minutes, or many other projects like that which no normal company would ever consider. If it gets some project team to cut delivery times by 3 weeks, it's all considered worthwhile.
Where we run into trouble is when we try to copy the shape of those big companies, and the kind of initiatives they fund, into startups, or mid-range companies. In quite a few ways, those top companies are better at development, but the base costs are only worthwhile if you have a money fountain of real revenue that grows far faster than your dev expenses. Trying to copy them with very different conditions is going to lead to tough problems, possibly company killing, and it's the kind of imitation we see all over the industry.
So yes, someone like Github is going to have eye popping expenses, because the alternatives to avoid those expenses just don't make sense to them. If you are not working in a multi billion dollar company, their practices can be interesting, but it makes as much sense to emulate them as it'd make for you to hire an entire Formula 1 pit crew to keep your commuter car in good shape.
Just guessing, not basing it on fact, but I suspect all software is just significantly more complex and higher featured than it was in the past.
Every website interacts with 50 million api, every app has a broad requirement for custom bespoke interfaces and features, or just implementations that need custom integration into your app.
So you end up needing massive teams with massive stacks.
The building blocks are not just helping, they have become necessary. Without them it'd already be impossible to manage and maintain the current software + infra features.
For backend internal systems, yeah you can still crap those out pretty cheap from what I've seen - minus devs being expensive.
I talked to someone who worked in this team. A mere 30 min conversation opened my eyes to the complexity and he wasn’t even scratching the surface. It’s hard for most people to appreciate the true complexity here. I agree that accountability is needed but even a trillion dollars won’t be enough for bug free code - especially with dates.
Can't build quickly because of all the middleman bloat. It's happening in IT...look at how big your product teams are. Software was so much better and faster before agile and product teams. Takes 50 coders a year to make a basic website.
This type of bureaucracy is not only harmful to dev culture, it's also outrageously expensive. I've been on an engagement with a large healthcare provider and the dev culture there is very similar to Amazon, loads and loads of procedure and bureaucracy. Now i get a certain level of that at any company, but you often find yourself going: "does it really need to be this hard". Tasks that would take you an hour outside of this companies ecosystem would take you 3-4 inside the ecosystem.
It's annoying to devs but should be alarming to management. You're literally spending 2x to 3x the required amount on your labor because of your inefficiencies. Personally I found it easy to convince management of changes like this when you pitch it like: "How would you like to reduce your labor costs by 2x". Now granted many people at these places are salaried which makes this a bit of a moot point but most software shops contract out alot of work, and that's where you're really paying for your inefficiencies.
Another reason I'd like to add regarding why so many software projects fail is a really basic one, but is ultimately the reason why most software projects fail.
The budget isn't there.
For many, building software is a race to the bottom. I've worked at countless places, from "Wagile" places that run spiral methodologies mixed with agile, to fully agile agencies that deliver well but crumble the second a client gets pissy about something taking longer/costing more than it should.
In my view, the most basic problem in software is that we're committing to too much for too little, which is why I see development to be similar to working in a skilled trade. If you pay good money for a renderer, you'll get the outside of your house rendered nicely with good advice on what to use, what looks good. They'll also tell you how long it'll take, and if you say you want it sooner they'll tell you it'll either cost a lot more to get more manpower, or they'll decline the job. If you are cheap about it, you'll probably get someone that'll take longer than expected, will make a mess of the job, and you'll be left with something you're not entirely happy with.
A solid methodology will probably help with delivering software on time and on budget, but if you are unrealistic with either metric then it doesn't matter what methodology you use. You'll take liberties with it, decide that it's bullshit, and continue to cowboy your way towards a duct-taped mess of a solution.
It's something few want to talk about, probably because there isn't really a solution to it outside of:
* Paying a premium for a development team with a track record of recent success
* Having people that know the full software lifecycle be involved in all parts of the process
* Actually embracing the fact that when requirements change, to the point where budgets and timescales are flexible.
Same reason why building a house is so much more difficult than it was years ago - mind numbing, overwhelming bureaucracy. It's easier than ever to solve an important personal, business or non profit need in 10 lines of code, but coding environments are not optimized for such needs. Everything has to be portable, and scalable, and localizable and accessible and graphical and event driven and tools wouldn't let you just have user fill in a single language form from beginning to end and press a button to process it using high school level math or 70s era text parser. What is forgotten is how many ideas need to start quick and dirty and gradually mature if rising need justifies the resources.
I've spent 2 years in a fairly large bank, and I heavily disagree. We have tons of procedures and edge cases that are subtlely unique.
Our problem is purely one of speed. When there's 3 quarters and 5 org layers between you and the developer, you are much more likely to just grab a tool you have access to and get to work.
Same here. A while I ago I wrote a pretty complex app for test management alone with WPF in a few months. With synchronization to a server database, lots of concurrency and a lot of other stuff. Talked to users about their needs and came up with a design. Then two of us ported it to a web in a few months.
Now I have to lead development of a site that pretty much does simple CRUD and between offshore devs, proofs of concept, approvals, other teams in the corp, spec writing and reporting to management 10 devs will develop something that's technically inferior and ugly in more time. It's very frustrating.
Exactly. I used to work with a government contracting company. The simplest piece of software took many thousands of dollars in lawyer fees and compliancy.
A beginner dev could build many simple web applications in a day. However, it will probably have security holes and spaghetti code.
One reason many Web apps are so sleek and fit is that the developers could code, release, judge, and repeat daily.
This is much harder to do with large entities, who a) will need to present Accounting with the One True Final Cost for pre-approval and budgeting, and b) will need to have Official Sign-Off on the Absolute Final Specs from some dozen department heads.
reply