Why can't the IT industry deliver large, faultless projects quickly?(softwareengineering.stackexchange.com)
softwareengineering.stackexchange.com
Why can't the IT industry deliver large, faultless projects quickly?
https://softwareengineering.stackexchange.com/questions/158640/why-cant-the-it-industry-deliver-large-faultless-projects-quickly-as-in-other
86 comments
Losing a plane full of people is a tragedy. Losing a few million passwords is not. Actually, my email addresses and passwords have been leaked many times and it's not a big deal. Makes a barely noticeable difference to my spam folder.
These are very different levels of risk. Of course they are approached differently.
These are very different levels of risk. Of course they are approached differently.
> Losing a few million passwords is not.
Just because you've never been adversely affected doesn't mean other people's lives aren't ruined.
What about people who have unsavory things leaked about them? (Gay people still in the closet from their ultra-conservative families? Religious people who leave their faith?) What about people who are blackmailed? What about women's private nude pictures? I think they care whether their accounts are compromised.
We have privacy for a reason. It's valuable. And the more we depend on the internet for our lives, placing our private actions (nudity, conversations with our closest friends and family) onto the internet, the more valuable it is to hack and breach it. The more our society values witchhunts, the more valuable it is to breach security to find new savory details to feed those witchhunts.
Imagine if you took an innocent photo of your toddler, naked, in the bathtub. And then found out it was being traded on a pedo ring. You'd feel pretty violated. And then you found out your home address and your child's school address was posted online there. You'd feel pretty scared at that point.
Just because you've never been adversely affected doesn't mean other people's lives aren't ruined.
What about people who have unsavory things leaked about them? (Gay people still in the closet from their ultra-conservative families? Religious people who leave their faith?) What about people who are blackmailed? What about women's private nude pictures? I think they care whether their accounts are compromised.
We have privacy for a reason. It's valuable. And the more we depend on the internet for our lives, placing our private actions (nudity, conversations with our closest friends and family) onto the internet, the more valuable it is to hack and breach it. The more our society values witchhunts, the more valuable it is to breach security to find new savory details to feed those witchhunts.
Imagine if you took an innocent photo of your toddler, naked, in the bathtub. And then found out it was being traded on a pedo ring. You'd feel pretty violated. And then you found out your home address and your child's school address was posted online there. You'd feel pretty scared at that point.
The most contrived examples you come up with are still vastly better outcomes than 150 people perishing in a plane crash. The stakes are just much, much lower.
We see class actions and government intervention over things like wristbands that give a small percentage of people rashes, antennas that perform poorly if you hold your phone in a certain away, or devices that fail just out of warranty.
I think the difference is they're extensions of laws for more egregious things like; things that electrocute you, things that give you cancer, or things that explode. (I'm sure another factor is that physical things have been sold for much longer than digital things) Since digital things don't have those catastrophic examples, the other violations don't have the same protections.
I think the difference is they're extensions of laws for more egregious things like; things that electrocute you, things that give you cancer, or things that explode. (I'm sure another factor is that physical things have been sold for much longer than digital things) Since digital things don't have those catastrophic examples, the other violations don't have the same protections.
A small bug in software that was used in Challenger brought down the entire space shuttle, killing all of its crew.
Challenger was destroyed by a disintegrating solid rocket. Given that a solid rocket cannot be shut down, what kind of software change could ever save them?
Solid rockets that detach. So, at least in theory, could have ejected the rockets. Or detached the shuttle from the whole tank and land. If you can detect the rocket's about to blow, of course.
Ditching the tank might help, but I wonder whether the control surfaces are quick enough to prevent tumbling in the hypersonic airstream.
I believe you are thinking of NASA's Mars lander.
http://articles.latimes.com/1999/oct/01/news/mn-17288
The ExoMars mission apparently had a software bug that crashed the lander.
https://www.forbes.com/sites/bridaineparnell/2016/10/26/soft...
http://articles.latimes.com/1999/oct/01/news/mn-17288
The ExoMars mission apparently had a software bug that crashed the lander.
https://www.forbes.com/sites/bridaineparnell/2016/10/26/soft...
The IT industry regularly does exactly that. The other engineering disciplines get too much credit for being executed perfectly according to plan and delivering flawless results.
Examples:
Bridges that have cracks. Roads that become too slippery when it rains. Railways that require immediate reconstruction after the first month of operation. Delays, environmental disasters, multi-million projects that become multi-billion projects. Projects that are ten years late...
The Airbus A380 mentioned in the question probably has thousands of defects but it's still a very successful project. On the software side I could mention Windows 10, most triple-A games and Tesla's autopilot. Of course these products have defects. But they're still very successful projects. Give them some credit.
Examples:
Bridges that have cracks. Roads that become too slippery when it rains. Railways that require immediate reconstruction after the first month of operation. Delays, environmental disasters, multi-million projects that become multi-billion projects. Projects that are ten years late...
The Airbus A380 mentioned in the question probably has thousands of defects but it's still a very successful project. On the software side I could mention Windows 10, most triple-A games and Tesla's autopilot. Of course these products have defects. But they're still very successful projects. Give them some credit.
Funny that they mention the A380 specifically because it was actually finished several years behind plan and billions of dollars above budget.
http://calleam.com/WTPF/?p=4700
http://calleam.com/WTPF/?p=4700
Very funny. I should probably edit my comment to say "may very well have been a successful project" but I like the way you burst that bubble so I'll leave it as it is. ;-)
It would be useful for software developers to really step out of software industry bubble.
I hear all the time about construction projects delays and you get a lot of physical products with faults.
Other thing we as software developers live in is hiring process. I do not even know what could be hiring process for chemical engineer or something like that.
I hear all the time about construction projects delays and you get a lot of physical products with faults.
Other thing we as software developers live in is hiring process. I do not even know what could be hiring process for chemical engineer or something like that.
> I do not even know what could be hiring process for chemical engineer or something like that.
They must make you do chemistry brain teasers on a whiteboard right?
They must make you do chemistry brain teasers on a whiteboard right?
Agree, just look at the "new" Airport in Berlin, which will probably never go live.
The I-12 median barrier that significantly worsened the Baton Rouge area 2016 flood.
Also Apple has mastered execution pretty well.
My view is that the single most important cause for this effect is the low cost of failing: Because software is immaterial, the cost of a fault is usually fairly small (in that it's rare that a bug breaks physical things), and the cost of fixing is also small. It happened to all of us: you ship a bug, someone notices it, you fix it, you ship an update, and it's done.
In other engineering disciplines, failing is often life-threatening and the cost of fixing the problem can skyrocket pretty fast.
So, in IT, faultlessness does not weigh very much against time-to-market or development costs.
In projects were IT faults could be lifethreatening, you generally see much higher quality standards
In other engineering disciplines, failing is often life-threatening and the cost of fixing the problem can skyrocket pretty fast.
So, in IT, faultlessness does not weigh very much against time-to-market or development costs.
In projects were IT faults could be lifethreatening, you generally see much higher quality standards
I blame changing requirements. I've yet to see a large project which hasn't changed its requirements along the way. On the other hand airplanes are designed tested in small scale for proof of concept and specs are finalised before any production work begins.
Now that you say it, I believe that there are several (military) aircraft projects that have huge delays exactly due to changing specifications. The people making the contracts did not have a clear vision about what they actually want and there are several parties involved who want different things crammed into one vehicle. As the process moves on, the requirements get adjusted to meet the new political power balance.
The commerical planes, I believe, were designed with a clear goal and are in many ways an incremental improvement on the previous (proven to work well) models.
So in essence you need: A clear vision of something that is acutally achievable. Plus you need to communicate that vision.
The commerical planes, I believe, were designed with a clear goal and are in many ways an incremental improvement on the previous (proven to work well) models.
So in essence you need: A clear vision of something that is acutally achievable. Plus you need to communicate that vision.
"On the other hand airplanes are designed tested in small scale for proof of concept and specs are finalised before any production work begins."
Let me introduce you to the F-35 and let's see how you react to that.
Let me introduce you to the F-35 and let's see how you react to that.
This actually proves my point that having a solid spec also means a quicker project completion.
Writing a solid spec isn't free either. You spend 5 years on writing a spec and 1 year implementing, instead of the other way around.
The spec was solid - superior LAS capability over F-22 and F-16 and F-14. How to get that spec realized, well...
Can you expound on that?
Its easier to fudge the numbers when you are dealing with something that isn't physically tangible.
In my experience some or all of the following will happen on big software projects...
The sales team will bid unrealistically to get the contract, either by underestimating development time or by bidding too low. They will also ignore the advice of experienced devs an PMs when planning their bid.
On winning the bid there will be a ruthless focus on doing things as cheaply as possible. A PM with no experience of this type of project will be put in charge. The rest of the team will largely be chosen based on availability rather than skills or experience. The positions of software architect or technical lead will be seen as optional.
Whatever PM methodology is chosen (probably Scrum), no one will really understand the finer details of how it works. Work will be divvied up poorly, e.g. tasks that need two people working on it together will be given to one person and vice versa.
There will be no thought given to training. Devs will arrive in to find out they are working on some hyper complex financial system, but they will never be given training on what that system is for or how it works.
Inevitably the specs as defined in the bid document will be discovered to be incomplete or faulty. No one will want to actually change the specs, but somehow the devs will be expected to just deal with it.
If the contract is time and materials based as opposed to fixed price then the contractor will massively over-resource the project meaning you end up with a too many cooks situation.
The client will get wind that there are problems and raise concerns. The PMs and hgh-ups in the contracting firm will claim everything is Okay and demand devs work overtime to get things right. They may also utilize smoke and mirrors to fool the client.
As stress builds among the PMs they will start to micro-manage, this will alienate senior devs who know they don't need to take that and they may leave for pastures new. Junior devs will carry on despite still not having the required skills or experience. New devs will be hired, only to leave soon after when they realise that the place is in a mess.
Eventually the project will be delivered late and full of bugs, yet somehow the contractor firm will claim everything went great and organise a piss-up to celebrate.
In my experience some or all of the following will happen on big software projects...
The sales team will bid unrealistically to get the contract, either by underestimating development time or by bidding too low. They will also ignore the advice of experienced devs an PMs when planning their bid.
On winning the bid there will be a ruthless focus on doing things as cheaply as possible. A PM with no experience of this type of project will be put in charge. The rest of the team will largely be chosen based on availability rather than skills or experience. The positions of software architect or technical lead will be seen as optional.
Whatever PM methodology is chosen (probably Scrum), no one will really understand the finer details of how it works. Work will be divvied up poorly, e.g. tasks that need two people working on it together will be given to one person and vice versa.
There will be no thought given to training. Devs will arrive in to find out they are working on some hyper complex financial system, but they will never be given training on what that system is for or how it works.
Inevitably the specs as defined in the bid document will be discovered to be incomplete or faulty. No one will want to actually change the specs, but somehow the devs will be expected to just deal with it.
If the contract is time and materials based as opposed to fixed price then the contractor will massively over-resource the project meaning you end up with a too many cooks situation.
The client will get wind that there are problems and raise concerns. The PMs and hgh-ups in the contracting firm will claim everything is Okay and demand devs work overtime to get things right. They may also utilize smoke and mirrors to fool the client.
As stress builds among the PMs they will start to micro-manage, this will alienate senior devs who know they don't need to take that and they may leave for pastures new. Junior devs will carry on despite still not having the required skills or experience. New devs will be hired, only to leave soon after when they realise that the place is in a mess.
Eventually the project will be delivered late and full of bugs, yet somehow the contractor firm will claim everything went great and organise a piss-up to celebrate.
Great writeup!
Just one point regarding this: "The sales team will bid unrealistically to get the contract" - this happens also a lot in construction industry.
Just one point regarding this: "The sales team will bid unrealistically to get the contract" - this happens also a lot in construction industry.
In my experience it has been due to several glaringly obvious oversights and blunders.
1) Not empowering developers by blocking access to critical resources, basically walling them off in a tightly-controlled box and still expecting them to do their jobs because "they should be able to figure it out". Ridiculous shit like no admin rights, strict enforcement of specific tools,etc. This is usually due to an IT or security department with a inflexi,no fucks given, block everything attitude.
2) Not hiring a strong architect who has the vision for project and the power to make major decisions. So many organizations don't think this is necessary and often have someone in management play this role.
3) Having a weak management team that won't stand up to the customer to tell them what can and can't be done, and not letting them dictate how to do technical things.
4) Skipping or not enforcing basic well-established engineering practices such as design, testing, peer review, etc.
5) Using ill-advised "solutions" platforms that are not intended for engineers but for business analysts with some tech background. These platforms are sold to government and enterprise by used-car-salesmen-like sleazy marketing departments that straight up lie about capabilities or omit huge faults or inabilies. Stupid and/or tech-ignorant management buys this shit and it's crappy, expensive licenses for years to come. They can't get rid of it because of sunken costs, etc.
6) Fear of anything open source
7) Inability to find good, reliable talent -- anything from engineers to testers to tech writers (and who actually have good English skills). Many, many people I work with are great engineers but have such poor English skills that I literally can't understand a thing they're saying, even in an email.
8) Management or stakeholders straight up not giving a shit and letting the project die due to personal problems, infighting, interpersonal issues, corruption, etc. This I would say is the most important issue.
1) Not empowering developers by blocking access to critical resources, basically walling them off in a tightly-controlled box and still expecting them to do their jobs because "they should be able to figure it out". Ridiculous shit like no admin rights, strict enforcement of specific tools,etc. This is usually due to an IT or security department with a inflexi,no fucks given, block everything attitude.
2) Not hiring a strong architect who has the vision for project and the power to make major decisions. So many organizations don't think this is necessary and often have someone in management play this role.
3) Having a weak management team that won't stand up to the customer to tell them what can and can't be done, and not letting them dictate how to do technical things.
4) Skipping or not enforcing basic well-established engineering practices such as design, testing, peer review, etc.
5) Using ill-advised "solutions" platforms that are not intended for engineers but for business analysts with some tech background. These platforms are sold to government and enterprise by used-car-salesmen-like sleazy marketing departments that straight up lie about capabilities or omit huge faults or inabilies. Stupid and/or tech-ignorant management buys this shit and it's crappy, expensive licenses for years to come. They can't get rid of it because of sunken costs, etc.
6) Fear of anything open source
7) Inability to find good, reliable talent -- anything from engineers to testers to tech writers (and who actually have good English skills). Many, many people I work with are great engineers but have such poor English skills that I literally can't understand a thing they're saying, even in an email.
8) Management or stakeholders straight up not giving a shit and letting the project die due to personal problems, infighting, interpersonal issues, corruption, etc. This I would say is the most important issue.
9) Letting the sales guys write the spec, in the form of a powerpoint.
10) taking estimates from development and lopping off a big chunk plus adding extra scope, because “I couldn’t sell the original estimate” and “this project will be a great reference, so we can take the hit”
11) doing agile in the sense of changing scope / direction constantly, but requiring complete timelines for project delivery to check planned vs actuals.
12) the perennial favorite: having multiple managers who are too busy to talk to each other but not too busy to give conflicting instructions.
10) taking estimates from development and lopping off a big chunk plus adding extra scope, because “I couldn’t sell the original estimate” and “this project will be a great reference, so we can take the hit”
11) doing agile in the sense of changing scope / direction constantly, but requiring complete timelines for project delivery to check planned vs actuals.
12) the perennial favorite: having multiple managers who are too busy to talk to each other but not too busy to give conflicting instructions.
Most of the points above are very true, particularly 3,5,7,9,10,11 from my experience.
Additionally:
13) POs and devs accepting feature requests that don't add value but add a lot of complexity
14) Team members who add negative velocity and lower morale of everyone else in the project (but typically are highly regarded by the management who dismiss any complaints)
The core IMO is that most people (especially non-technical, but technical too) can not properly understand the complexity of a software project as it's not something tangible like a building or a bridge.
Additionally:
13) POs and devs accepting feature requests that don't add value but add a lot of complexity
14) Team members who add negative velocity and lower morale of everyone else in the project (but typically are highly regarded by the management who dismiss any complaints)
The core IMO is that most people (especially non-technical, but technical too) can not properly understand the complexity of a software project as it's not something tangible like a building or a bridge.
Oh God #10. I currently work for a project manager like this. He asks for LOE, and he rejects it, saying there's no way it could take that long. Then we'll be halfway through development, then told that in a week we're gonna go to production because that's what he promised to the stakeholders. He basically lies is ass off about delivery dates, then blames the devs for not delivering on time.
I think a lot of the reasons are related to the primacy of the project. The A380 was a bet-the-company move for Airbus and Emirates. This means that practically everyone at both those companies are aligned around the necessity to make the project a success, and there is a broad and shared understanding of the need to shape the world around the project for it's success.
Organisations often fail to realise the strategic importance of big IT projects, and fail to treat them accordingly. "The geeks" are tasked with figuring it out.
Whenever a new subway line is built in a city, years and years are spent moving existing underground infrastructure like sewers, water, gas and electricity. All sorts of weird complexity tends to bubble up around this time. A comparable IT project will typically have requirement 264/B-4: The project will be delivered without changing existing infrastructure.
This again probably has something to do with the sequestration of IT as a staff function. This is absolutely the correct place for the office that builds and supports workstations, runs the Exchange server and manages the Active Directory, but it is not where you anchor a large, strategically important project (IT is definitely an important stakeholder, but they don't own it). Emirates doesn't have a staff office tasked with buying, taking delivery and integration the A380 into the fleet, that is a project that spans the organisation and is run out of the CEOs office.
Tangentially to this, there are the complications around the fact that many large IT projects replace existing systems, sometimes decades old. I'm not sure there really is a good physical analogy to the ways old IT systems creep into and get entrenched in adjacent use cases, often without the system owners really realising. It's like Emirates realising two weeks before the inaugural flight of the A380 that there is something about the ailerons of the new plane that means half of the check-in staff can't get to work.
Organisations often fail to realise the strategic importance of big IT projects, and fail to treat them accordingly. "The geeks" are tasked with figuring it out.
Whenever a new subway line is built in a city, years and years are spent moving existing underground infrastructure like sewers, water, gas and electricity. All sorts of weird complexity tends to bubble up around this time. A comparable IT project will typically have requirement 264/B-4: The project will be delivered without changing existing infrastructure.
This again probably has something to do with the sequestration of IT as a staff function. This is absolutely the correct place for the office that builds and supports workstations, runs the Exchange server and manages the Active Directory, but it is not where you anchor a large, strategically important project (IT is definitely an important stakeholder, but they don't own it). Emirates doesn't have a staff office tasked with buying, taking delivery and integration the A380 into the fleet, that is a project that spans the organisation and is run out of the CEOs office.
Tangentially to this, there are the complications around the fact that many large IT projects replace existing systems, sometimes decades old. I'm not sure there really is a good physical analogy to the ways old IT systems creep into and get entrenched in adjacent use cases, often without the system owners really realising. It's like Emirates realising two weeks before the inaugural flight of the A380 that there is something about the ailerons of the new plane that means half of the check-in staff can't get to work.
Because most IT projects are not really pure play IT projects? If we do a comparison with construction, once requirements are done, design is completed, it is civil engineers all the way through. But in IT it requires input from non-IT folks and the amount of disconnect is mind boggling. So say creating a product for a construction company, which can predict the stress on a building. It requires coders who have no formal education on this aspect to work with civil engineers who have no formal education on how software works. So both way communication tends to be terrible.
Then the questions are what exactly constitutes a project and what are failures? Taking the example of the quoted A380 example. Deliveries have been delayed: https://www.bloomberg.com/news/articles/2016-12-27/airbus-to...
And the engines the mainstay of a plane have found to be have problems: https://www.bloomberg.com/news/articles/2016-11-18/emirates-...
Then the questions are what exactly constitutes a project and what are failures? Taking the example of the quoted A380 example. Deliveries have been delayed: https://www.bloomberg.com/news/articles/2016-12-27/airbus-to...
And the engines the mainstay of a plane have found to be have problems: https://www.bloomberg.com/news/articles/2016-11-18/emirates-...
One essential part is managing complexity.
With a mechanical part it often is obvious to see and easy to understand what this part does. A lot of engineering goes into finding the right materials, the best shape and processing tools. But the finished part is easy to understand.
With software engineering we have abstractions like "sort algorithm" that are easy to understand but many things have so many cross-connections to other parts that in order to understand what is actually going on you have to get really deep into this stuff. Changing a detail in one implementation may lead to unforseen consequences on other, seemingly unrelated, parts. You may rely on undocumented features without even knowing that.
How many cables do you see when you cut a boeing in half? How many of them are essential to operating the plane? How many dangling pointers do you get if you cut your main memory in half? How many of them are of system components?
Whatever technique we have to cut down complexity, hide implementation details behind clear interfaces, separating stuff into easily-to-combine modules makes managing projects easier. I think that the main success factor of python lies in this area.
Then imagine a project that does not have all those modules readily available. That does not have engineers who know it all (and really do, not just pretend) in charge. They rough out a plan and start working on many ends that - when they meet - do not fit together. Add in organizational, personal, psychological problems and the structure wraps in on itself, turns on itself in infighting about how-to-do-stuff, career postions, blame, praise, just surviving or just passively standing by fulfilling orders on paper waiting until everything collapses.
With a mechanical part it often is obvious to see and easy to understand what this part does. A lot of engineering goes into finding the right materials, the best shape and processing tools. But the finished part is easy to understand.
With software engineering we have abstractions like "sort algorithm" that are easy to understand but many things have so many cross-connections to other parts that in order to understand what is actually going on you have to get really deep into this stuff. Changing a detail in one implementation may lead to unforseen consequences on other, seemingly unrelated, parts. You may rely on undocumented features without even knowing that.
How many cables do you see when you cut a boeing in half? How many of them are essential to operating the plane? How many dangling pointers do you get if you cut your main memory in half? How many of them are of system components?
Whatever technique we have to cut down complexity, hide implementation details behind clear interfaces, separating stuff into easily-to-combine modules makes managing projects easier. I think that the main success factor of python lies in this area.
Then imagine a project that does not have all those modules readily available. That does not have engineers who know it all (and really do, not just pretend) in charge. They rough out a plan and start working on many ends that - when they meet - do not fit together. Add in organizational, personal, psychological problems and the structure wraps in on itself, turns on itself in infighting about how-to-do-stuff, career postions, blame, praise, just surviving or just passively standing by fulfilling orders on paper waiting until everything collapses.
Interoperability and dependency also tends to play a very large part of why IT projects are notorious for getting side tracked, to jump off this post; at my last place of employment, the first major project we tried to tackle was finally migrating off of a legacy server which touched virtually every other piece of software and hardware on the campus due to how the infrastructure had grown over time. Every project was stalled largely due to the fact that everything was so dependent on this one system and the system itself was a complete unknown as it more or less was script-soup written by one guy over the course of 20 years. Detangling and decoupling everything took years, and was only finally completed when the server's mobo went belly-up on us and we weren't able to scavenge a new part.
With a lot of infrastructure projects, you can fairly easily route around dependencies since, luckily, in many cases modern cities have planned for it, or there are natural detours built in, but dependencies in IT can be literally hard-coded, and replacing then is not a minor task.
With a lot of infrastructure projects, you can fairly easily route around dependencies since, luckily, in many cases modern cities have planned for it, or there are natural detours built in, but dependencies in IT can be literally hard-coded, and replacing then is not a minor task.
Plus you can see the dependencies directly in "real" engineering. In software it's all completely invisible.
I always say that building software is like building a house, in the dark, with flashlights.
This also makes it immediately understandable why throwing more programmers at something doesn't always increase the development speed.
This also makes it immediately understandable why throwing more programmers at something doesn't always increase the development speed.
What seems to be missing (correct me if I'm wrong) is bad incentives. Software projects in government tend to be assigned by two ways:
1) via tenders, where it's a race to the price bottom, and the vendors charge massive sums for change requests or simply to fix what should have worked in the first place, but the government must pay additional money in order to not have wasted the entire sum already spent
2) tenders with specs that are customized so only a select few (or one!) vendor hits the criteria (e.g. must have 20+y of government work history, x% of workers must have top-secret clearances) or lock-in; basically "no one ever got fired for buying IBM/Accidenture". The big vendors of course know this and charge govt through the nose.
Another reason especially in government is a lack of client-side controlling, i.e. there is no qualified staff to review code, architectural decisions or cost/time plannings early (if at all). This also hits home for construction projects.
1) via tenders, where it's a race to the price bottom, and the vendors charge massive sums for change requests or simply to fix what should have worked in the first place, but the government must pay additional money in order to not have wasted the entire sum already spent
2) tenders with specs that are customized so only a select few (or one!) vendor hits the criteria (e.g. must have 20+y of government work history, x% of workers must have top-secret clearances) or lock-in; basically "no one ever got fired for buying IBM/Accidenture". The big vendors of course know this and charge govt through the nose.
Another reason especially in government is a lack of client-side controlling, i.e. there is no qualified staff to review code, architectural decisions or cost/time plannings early (if at all). This also hits home for construction projects.
Two key reasons (others have been mentioned): the output is purely digital, and incredibly abstract. Code is very unique in this regard.
As a purely digital artifact, it is highly malleable. Yet its deeply abstract nature, and the complexity enabled by those abstractions, make software very difficult to inspect and understand, compared with the vast majority of things humans make.
As a purely digital artifact, it is highly malleable. Yet its deeply abstract nature, and the complexity enabled by those abstractions, make software very difficult to inspect and understand, compared with the vast majority of things humans make.
I think part of it has to do with complexity. For a roadway, it must be tested within a specific temperature range and weight range. For software, it's considered a failure if anything can break it, foreseen or unforeseen.
If roads were tested like software, you could say "yeah, it supports all the common/pre-defined use cases, but we just found out it's susceptible to a jackhammer. Better fix that." And then your road would never be finished just as software is never finished.
If roads were tested like software, you could say "yeah, it supports all the common/pre-defined use cases, but we just found out it's susceptible to a jackhammer. Better fix that." And then your road would never be finished just as software is never finished.
Our tools & materials are constantly changing... not to mention that every project is different in various ways (though many developers delude themselves into thinking their project is unique i.e. the snowflake effect). I've found the most success when I stick to tools/patterns/strategies that I've had some degree of success with in the past.
...because the hiring process is very broken, and you end up with a Team that's a mix of a small number of super smart engineers, a good size of average engineers, a lot of incompetent engineers, and a couple of toxic engineers. All with varying levels of communication and soft skills.
Now throw in a good measure of politics with a dash of bureaucracy and you have your answer.
Now throw in a good measure of politics with a dash of bureaucracy and you have your answer.
The hiring process hires exactly the people that it was designed to. You do not want a team that excels in every aspect. How would you manage such a team? They would go off in directions you cannot control anymore and you have no way of stopping them taking your position.
This is the illustrated version of the discussion:
http://www.projectcartoon.com/pdf.php?CartoonID=2&PaperSize=...
http://www.projectcartoon.com/pdf.php?CartoonID=2&PaperSize=...
Is there a precedent in any field? Large, complex projects seem to inherently require delays due to the discovery of new facets of the project.
In Norway big road-building projects involving complex bridges and tunnels are done mostly on time. When they are not on time these days, the delays quite likely come from IT. For example, 2 years ago tunnel opening was postponed by few months due to the need for extra camera testing that came from fixing some software issues.
There are three levels at work in IT. First, it's important to understand that all IT work is carried out by vendors or providers of some sort. Either a IT vendor or internal IT group which is essentially still a vendor (often shared services) to the business, albeit part of the same company.
This can be broken into three levels of hierarchy.
The executive level is the level VP and above - they write checks. If you don't spend the company's money - you are not at this level. They spend money on programs. They don't know or need to know (or care about) specifics. They are only concerned with the investment and not even individual investments but the organization as a whole.
The bottom level is the IT worker. They are the programmers, managers, etc.. that carry out the specific tasks, do the work.
In between is the (often called Sr. Managers, Acct execs, or VPs in consulting). Not straight sales guys (which is a specific skill, and who are specifically there to close, that's a different breed).
These are the schmoozers. Project people (level 3) have to report to them and they typically hold pretty decent amount of power (reporting to the CEO of a smaller IT consulting or svcs firm, or a COO or SVP in a larger firm). They get credit, sometimes deserved, for bringing in business, so they have power - AND they are often completely incompetent in knowing what to look for and managing a project to success.
They have the power and they don't know what to do, or won't do it. The managers below them, experienced team leads, etc.. know what to do but don't have the power or resources under their control.
It fails at this level, and the level 3 folks (proj mangers, leads, dev, etc..) are not directed appropriately. They may be the greatest team leads and developers etc.. in the world, and the project still fails.
This can be broken into three levels of hierarchy.
The executive level is the level VP and above - they write checks. If you don't spend the company's money - you are not at this level. They spend money on programs. They don't know or need to know (or care about) specifics. They are only concerned with the investment and not even individual investments but the organization as a whole.
The bottom level is the IT worker. They are the programmers, managers, etc.. that carry out the specific tasks, do the work.
In between is the (often called Sr. Managers, Acct execs, or VPs in consulting). Not straight sales guys (which is a specific skill, and who are specifically there to close, that's a different breed).
These are the schmoozers. Project people (level 3) have to report to them and they typically hold pretty decent amount of power (reporting to the CEO of a smaller IT consulting or svcs firm, or a COO or SVP in a larger firm). They get credit, sometimes deserved, for bringing in business, so they have power - AND they are often completely incompetent in knowing what to look for and managing a project to success.
They have the power and they don't know what to do, or won't do it. The managers below them, experienced team leads, etc.. know what to do but don't have the power or resources under their control.
It fails at this level, and the level 3 folks (proj mangers, leads, dev, etc..) are not directed appropriately. They may be the greatest team leads and developers etc.. in the world, and the project still fails.
Because we can't estimate things well. We have played with small demos and examples, solved homework problems (in college). We remember how successful we were picking up and coding new APIs and ideas.
That is we often have a proof of concept ready or the skeleton and then declare it 80% done. Then we extrapolate and say, "well I'll a bit more just to finish the last 20%". Except that the last 20% is composed of both boring and unpredictable things. Boring like having to write tests, documentation, find out that it doesn't jive with the deployment hardware, plugging logging, authentication into it, managing upgrade from old versions of software, having meetings with marketing. Unpredictable because in that perceived 20% requirements change. Even more insidious is the market as a whole change. Ever seen it happen - while finishing a major project and about ready to release it, everyone moved on and nobody wants that kind of a thing anymore? I've seen it.
That is we often have a proof of concept ready or the skeleton and then declare it 80% done. Then we extrapolate and say, "well I'll a bit more just to finish the last 20%". Except that the last 20% is composed of both boring and unpredictable things. Boring like having to write tests, documentation, find out that it doesn't jive with the deployment hardware, plugging logging, authentication into it, managing upgrade from old versions of software, having meetings with marketing. Unpredictable because in that perceived 20% requirements change. Even more insidious is the market as a whole change. Ever seen it happen - while finishing a major project and about ready to release it, everyone moved on and nobody wants that kind of a thing anymore? I've seen it.
The gaming industry routinely deliver "large, faultless projects" within 6-9 months timeframe. Searching for "data-oriented programming" gives some hints how they do it. Another part of the story is proper project management.
The gaming industry is also full of horror stories about people burning out, months of crunch time and so on.
>within 6-9 months timeframe
Can you name any title that was developed in that timeframe? With yearly release cycles, it's easy to think they're pumping out projects in less than 12 months, but in reality each title takes years to finish, and the yearly releases are accomplished by using multiple studios/teams and pipelining.
Can you name any title that was developed in that timeframe? With yearly release cycles, it's easy to think they're pumping out projects in less than 12 months, but in reality each title takes years to finish, and the yearly releases are accomplished by using multiple studios/teams and pipelining.
They do? Can you name some examples?
The very beginning of [1] in the introduction of the speaker gives game titles.
[1] - https://youtu.be/rX0ItVEVjHc
[1] - https://youtu.be/rX0ItVEVjHc
Insomniac has two studios, one in Burbank, another is in Raleigh. It also does multiple projects at once in the Burbank so no, they are not delivering two console games a year. In fact, since 1996 they've done it only in 4 years (with the second game being a R&C game, which is more of a game design than a programming project) just as many years as they have not released a single game. Each of their big games is 2 years+, just like any other AAA studio. They start pre-production on the next project in the middle of the current one, just like any other AAA studio. 6-8 months in the console games nowadays is either a port (porting a game from one platform to another) or some horrible shovelware you find in the happy meals. In 6th generation a AAA game could be 12-18 months and if you worked really hard you could do something like Rogue Leader in 9. But 6 months is something from the 8 bit era, before Insomniac's times.
Sorry, I tend not to read hn in places I can watch a video. Maybe I'll remember to check it later.
That question is talking about a TV show that cherry picks the best examples of engineering projects, and shows the results on their launch date. But we see all IT projects and have to live with their ongoing status under daily use, as business grows and changes around the systems. Those are completely different measuring sticks. I'm sure that if you were to go hire people to go find the best IT projects and do a documentary about them, you'd find enough to fill a TV show, too. That doesn't mean there are not failures in both arenas, as well as successes... it just means you see much more when working in IT than you do on TV.
Being late on a software project is actually profitable.
Being late on an aircraft or building probably comes with financial penalties.
Being late on an aircraft or building probably comes with financial penalties.
The big contracted/outsourced projects usually have equally big penalties clause in their contracts. It doesn't really help.
The premise is wrong - large complex projects breaking new ground are often late, over budget and error prone in other industries as well.
The question uses Airbus A380 as an example of a complex project that was delivered in just five years. But according to Wikipedia the project started around 1990 which adds 10 years to the timescale, and the project actually had multiple delays https://en.wikipedia.org/wiki/Airbus_A380#Production_and_del... and multiple issues were found (and fixed) after delivery. This is not at all surprising given the scope of the project, but it is strange to present this as delivering a faultless project quickly.
"Airbus cited as underlying causes the complexity of the cabin wiring (98,000 wires and 40,000 connectors), its concurrent design and production, the high degree of customisation for each airline, and failures of configuration management and change control" - does this sound familiar?
Of course, when the model have been designed and tested, it is pretty predictable and low-risk to build the next one to the same specs, just like it is pretty predictable to build a standard building according to well-tested plans. But this is comparable to installing an existing tested software package on an new computer, which is also pretty predictable.
The question uses Airbus A380 as an example of a complex project that was delivered in just five years. But according to Wikipedia the project started around 1990 which adds 10 years to the timescale, and the project actually had multiple delays https://en.wikipedia.org/wiki/Airbus_A380#Production_and_del... and multiple issues were found (and fixed) after delivery. This is not at all surprising given the scope of the project, but it is strange to present this as delivering a faultless project quickly.
"Airbus cited as underlying causes the complexity of the cabin wiring (98,000 wires and 40,000 connectors), its concurrent design and production, the high degree of customisation for each airline, and failures of configuration management and change control" - does this sound familiar?
Of course, when the model have been designed and tested, it is pretty predictable and low-risk to build the next one to the same specs, just like it is pretty predictable to build a standard building according to well-tested plans. But this is comparable to installing an existing tested software package on an new computer, which is also pretty predictable.
Because no industry can deliver large, faultless projects quickly. What a strange question.
My feeling is that it's easier to tell if you're doing the right thing in some of these projects - e.g "Yes, we are building a big concrete wall that will hold back water" etcetera. Also, these projects are undertaken by teams of professionals who are working in a more or less well understood field.
Conversely, in a software project neither of those things may be true. Imagine the "reset password" feature. Sure, it reset the password for your test account. What about a student account created before 2010 (when there was that big accounts change) with restricted ads, from China, marked for suspicion of fraud and the account details service is responding slower than usual... plus, the feature was written by an intern in his second year of a CS degree.
Conversely, in a software project neither of those things may be true. Imagine the "reset password" feature. Sure, it reset the password for your test account. What about a student account created before 2010 (when there was that big accounts change) with restricted ads, from China, marked for suspicion of fraud and the account details service is responding slower than usual... plus, the feature was written by an intern in his second year of a CS degree.
In addition to all the other reasons, the IT industry is much, much younger than other industries. The 'web' itself is only 26 years old, shorter than a single person's career. Punchcards were still in common use in the late 70s, again within the reach of a single person's career.
[deleted]
Regulation, and taking advantage of current practices?
Any aviation or civil engineering project is in a highly regulated environment, and lives can be spectacularly lost if the product fails.
Lawsuits and criminal charges would likely be large and numerous if such a project failed, and was built with entirely new processes and technologies that were seemingly chosen on the whim of a project leader and their people, combined with "something we found on github." (I'm guessing there's no such thing as github for civil or aerospace engineering.)
If your environment constrains you in some dimension, then you're not going to spend much time and resources discovering new ways to stretch that dimension.
"Cherish your constraints," if you will.
Any aviation or civil engineering project is in a highly regulated environment, and lives can be spectacularly lost if the product fails.
Lawsuits and criminal charges would likely be large and numerous if such a project failed, and was built with entirely new processes and technologies that were seemingly chosen on the whim of a project leader and their people, combined with "something we found on github." (I'm guessing there's no such thing as github for civil or aerospace engineering.)
If your environment constrains you in some dimension, then you're not going to spend much time and resources discovering new ways to stretch that dimension.
"Cherish your constraints," if you will.
According to wikipedia the road from R&D conception to commercial deployment with Singapore Airlines for the A380 spanned almost 20 years, from 1988 to 2007.
How many software projects have that sort of scope?
How many software projects have that sort of scope?
[deleted]
My initial response is that the software industry doesn't actually do projects of that scale and with that kind of budget very often.
Unless you're working at Google scale, what's the budget for your website project? $100k? $200k? Departmental budget of $3million a year which is 90% salaries and 10% hardware?
Generally speaking, those businesses handling airplanes, submarines, skyscrapers etc are always working at that scale and everyone is prepared for that.
Unless you're working at Google scale, what's the budget for your website project? $100k? $200k? Departmental budget of $3million a year which is 90% salaries and 10% hardware?
Generally speaking, those businesses handling airplanes, submarines, skyscrapers etc are always working at that scale and everyone is prepared for that.
I think part of the problem is that the scale of software far higher than its price may imply. It’ll last as long as any bridge and may very well serve as many people, but it’ll cost 1/100 the price.
A bank’s software is an example of this.
A bank’s software is an example of this.
Few people see IT as anything but a cost, When companies run a tender, they go with the lowest cost bidder.
Companies that bid, also have twisted priorities, the people who do the bidding, aren't the people that have anything to do with the project, they more onto the next bid.
Companies that bid, also have twisted priorities, the people who do the bidding, aren't the people that have anything to do with the project, they more onto the next bid.
edge-cases. I feel like edge cases balloon exponentially relative to data size, where it feels as if at some point you might as well just screw the automation and handle each entry individually. Who cares, it's never going to be 'complete' anyway.
Complexity. As many others have also listed reasons why, systems today are made using needlessly complex designs because of a lack of skill and for speed of deployment.
I wonder if the Airbus A380 would be possible without the software it uses to operate it?
Easy to answer: human nature / society/ economy
Quality. Speed. Price. Pick any two.
Requirements != Expectations
Well, there are a few reasons. Before I begin though, it's probably best I mention that every industry has its faults. The difference in a lot of cases is merely between fixing all the ones normal people would encounter in every day life and trying in vain to fix everything. You'll never do the latter in a million years.
But the difference is likely that:
1. Time frames are quicker in IT fields, especially web development fields. So corners are cut and things are rushed to get them out the door. Same deal in games, where publishers assume they can release now and patch later.
2. There are stricter regulations in other fields. Not surprising cause they need them, the consequences are higher if things go wrong. Meanwhile IT projects (especially on a smaller scale/outside the finance industry) can be summed up as 'if it works, it's good'. Same with game development.
3. Human attacker risks are lower in many fields. This comes down to two things:
A: There's less of an incentive to 'test' non IT projects. For IT stuff like sites, breaking them can mean money from bounties (at the good end) and data to sell to criminals (on the negative end). For games, it can mean distributing pirated copies via torrent sites or gaining access to the console hardware. For an aeroplane or building? Why would anyone need to find faults? At least outside of internal testing or certification services...
B: It's much easier for them to find faults. They can attack an IT project without leaving the house, and they obviously have physical/file access to any games they own. No one has easy access to test buildings or large vehicles.
4. The risks provide a greater incentive to 'do things right'. If the worst that can happen is a site crashes/gets hacked, or even that the user finds a few random small bugs, there's less of an incentive than if the risk is loss of life or a huge financial loss.
5. A lack of standardisation or 'best practices'. People know what's good in vehicle or building design, and most are very much like others of the same type. Websites are mostly unique from each other, and games are often similar. There's a lot more uncharted territory there.
6. Careful planning is more common in some fields than others. A plane or building is probably not going to be revised very much, especially if there's no pressing reason to revise it mid development. A website or app may well be (especially if the client keeps changing them mind), and a game often will be as well (if something either isn't turning out to be fun, or the management decide the latest hot idea has been incorporated now). So the time available for testing and proper development can be limited due to constantly changing demands.
And yes, I feel the 'managing complexity' aspect brought up by static_noise is relevant here too. It's easier to figure out what each part of a mechanical system does than it is to do the same with a computer program or script. That's why large sandbox type games (like say, Zelda Breath of the Wild) can get rather buggy if you try unusual things. Because no Q/A team on the planet can find every odd thing a player could try and get the developers to implement a logical response to it. No one's going to find stuff like that which Stryder7X shows in his videos without being either going well out of their way to try insane things or being shown them:
https://www.youtube.com/watch?v=XFWjGXmnpno
Either way, there are lots of reasons really.
But the difference is likely that:
1. Time frames are quicker in IT fields, especially web development fields. So corners are cut and things are rushed to get them out the door. Same deal in games, where publishers assume they can release now and patch later.
2. There are stricter regulations in other fields. Not surprising cause they need them, the consequences are higher if things go wrong. Meanwhile IT projects (especially on a smaller scale/outside the finance industry) can be summed up as 'if it works, it's good'. Same with game development.
3. Human attacker risks are lower in many fields. This comes down to two things:
A: There's less of an incentive to 'test' non IT projects. For IT stuff like sites, breaking them can mean money from bounties (at the good end) and data to sell to criminals (on the negative end). For games, it can mean distributing pirated copies via torrent sites or gaining access to the console hardware. For an aeroplane or building? Why would anyone need to find faults? At least outside of internal testing or certification services...
B: It's much easier for them to find faults. They can attack an IT project without leaving the house, and they obviously have physical/file access to any games they own. No one has easy access to test buildings or large vehicles.
4. The risks provide a greater incentive to 'do things right'. If the worst that can happen is a site crashes/gets hacked, or even that the user finds a few random small bugs, there's less of an incentive than if the risk is loss of life or a huge financial loss.
5. A lack of standardisation or 'best practices'. People know what's good in vehicle or building design, and most are very much like others of the same type. Websites are mostly unique from each other, and games are often similar. There's a lot more uncharted territory there.
6. Careful planning is more common in some fields than others. A plane or building is probably not going to be revised very much, especially if there's no pressing reason to revise it mid development. A website or app may well be (especially if the client keeps changing them mind), and a game often will be as well (if something either isn't turning out to be fun, or the management decide the latest hot idea has been incorporated now). So the time available for testing and proper development can be limited due to constantly changing demands.
And yes, I feel the 'managing complexity' aspect brought up by static_noise is relevant here too. It's easier to figure out what each part of a mechanical system does than it is to do the same with a computer program or script. That's why large sandbox type games (like say, Zelda Breath of the Wild) can get rather buggy if you try unusual things. Because no Q/A team on the planet can find every odd thing a player could try and get the developers to implement a logical response to it. No one's going to find stuff like that which Stryder7X shows in his videos without being either going well out of their way to try insane things or being shown them:
https://www.youtube.com/watch?v=XFWjGXmnpno
Either way, there are lots of reasons really.
Speaking as a mechanical engineer:
Another issue is simply encapsulation. You can encapsulate physical problems to reduce their complexity. A spring is a spring. We "could" use finite-element-analysis to make a spring that is also a damper, and a lever at the same time. But it's way more cost-effective and easier to reasonable when we use discrete components. A spring is a spring. A damper is a damper. You want both, you put them together.
We "could" create capacitors that are also inductors and resistors. But it's way easier to reason about them separately.
Like I said, a spring is a spring. It will never set off an atomic explosion. It will never turn into lead. It will never warp into a living person. You can reason about that spring and as long as you live within "safe" areas it will always act the way you expect it. You can easily predict the failure rate of a given spring for given environment of heat, forces, etc.
Meanwhile, you have an app. You think it's encapsulated. But it's not. Your app is a network app. That means the router could die or be misconfigured. The ISP could go down. You could forget to pay the ISP bill. The internet backbone could go down. And, not only that, it's not just "down" it could simply be "slower" or have a higher packet loss than normal, or end up sending duplicate packets.
We spend so much time trying KNOWING that things can fail anywhere along the line, we "fix" it by adding redundant, fault-tolerant, load balancing systems. Except each of those systems increase the complexity and can fail in even more ways!
And I haven't even discussed what the app does yet! And just being connected to the internet or another network machine and it's already exploded in ways that it could fail. Even the WIRES in the wall could be corroded, unplugged, or eaten by a rat. And, if the power goes out anywhere along the chain you could have problems. If the power "kind of" goes out and you don't have proper battery backup, it could introduce errors. A Windows Update can (and DOES) break products all the time. A Java Update can break things. A driver update can break things. A hard drive failing can subtly break your software. Any third-party software you use could have a hidden bug. A router could have ONE and only ONE port, or one cable with a slight kink in it, could have a higher error rate.
There's a famous story of back-in-the-day when mainframe actually failed at the same time every day. It failed when people walked over a specific TILE in the floor where the wires ran under it.
Meanwhile, that spring, sitting on a table in some warehouse will remain a spring till it rusts away a couple hundred years later. The spring constant won't change. It won't unravel. It won't leak your boss's e-mails. It'll still be a spring.
So while yes, there ARE very complex mechanical constructs. However, they're actually pretty rare because in the physical world "simple" is the most reliable and often the strongest solution. Meanwhile, in business, you're dealing with tons of logic and even though you "think" it's encapsulated, it's actually not.
Summary / TL;DR: Most mechanical machines aren't dealing with the dimensional explosion of possibilities. They do have failure points just not as many.
(Also, one great thing about many machines is because they're physical, you can often diagnose many of them before they fail. They vibrate. They create sound. They output less than they're supposed to. A router doesn't warn you before it decides to stop forwarding a port.)
Another issue is simply encapsulation. You can encapsulate physical problems to reduce their complexity. A spring is a spring. We "could" use finite-element-analysis to make a spring that is also a damper, and a lever at the same time. But it's way more cost-effective and easier to reasonable when we use discrete components. A spring is a spring. A damper is a damper. You want both, you put them together.
We "could" create capacitors that are also inductors and resistors. But it's way easier to reason about them separately.
Like I said, a spring is a spring. It will never set off an atomic explosion. It will never turn into lead. It will never warp into a living person. You can reason about that spring and as long as you live within "safe" areas it will always act the way you expect it. You can easily predict the failure rate of a given spring for given environment of heat, forces, etc.
Meanwhile, you have an app. You think it's encapsulated. But it's not. Your app is a network app. That means the router could die or be misconfigured. The ISP could go down. You could forget to pay the ISP bill. The internet backbone could go down. And, not only that, it's not just "down" it could simply be "slower" or have a higher packet loss than normal, or end up sending duplicate packets.
We spend so much time trying KNOWING that things can fail anywhere along the line, we "fix" it by adding redundant, fault-tolerant, load balancing systems. Except each of those systems increase the complexity and can fail in even more ways!
And I haven't even discussed what the app does yet! And just being connected to the internet or another network machine and it's already exploded in ways that it could fail. Even the WIRES in the wall could be corroded, unplugged, or eaten by a rat. And, if the power goes out anywhere along the chain you could have problems. If the power "kind of" goes out and you don't have proper battery backup, it could introduce errors. A Windows Update can (and DOES) break products all the time. A Java Update can break things. A driver update can break things. A hard drive failing can subtly break your software. Any third-party software you use could have a hidden bug. A router could have ONE and only ONE port, or one cable with a slight kink in it, could have a higher error rate.
There's a famous story of back-in-the-day when mainframe actually failed at the same time every day. It failed when people walked over a specific TILE in the floor where the wires ran under it.
Meanwhile, that spring, sitting on a table in some warehouse will remain a spring till it rusts away a couple hundred years later. The spring constant won't change. It won't unravel. It won't leak your boss's e-mails. It'll still be a spring.
So while yes, there ARE very complex mechanical constructs. However, they're actually pretty rare because in the physical world "simple" is the most reliable and often the strongest solution. Meanwhile, in business, you're dealing with tons of logic and even though you "think" it's encapsulated, it's actually not.
Summary / TL;DR: Most mechanical machines aren't dealing with the dimensional explosion of possibilities. They do have failure points just not as many.
(Also, one great thing about many machines is because they're physical, you can often diagnose many of them before they fail. They vibrate. They create sound. They output less than they're supposed to. A router doesn't warn you before it decides to stop forwarding a port.)
Politics.
What aspects of politics?
How do they interact with engineering?
How do they interact with engineering?
Politics between the decision makers, especially in middle management. I see that quite often. They set a budget and deadline but keep changing requirements, arbitrarily choose systems you have to use but also often avoid making important decisions when needed.
Yes, it certainly isn't partially the responsibility of developers.
Surely it's fine that moaning about how doing design before writing code is boring, a waste of time (because it's "just documentation that won't apply at the end of the project anyway"), or beneath them (it's for people who aren't smart enough to write code). I've heard variations on all of these in person, and seen them in comments here on HN.
Gunning for the big glory of "saving the company" by re-writing the whole thing from scratch in Fancy New Language/Framework X certainly has nothing to do with it, right? This happens more often than some might care to admit.
Engaging in ego-stroking/pissing contests about CS trivia and minutiae instead of focusing on the broader engineering tasks and problems at hands is blame-free, yes?
This industry is absolutely packed with very smart people who, from an engineering perspective, fall quite short, mostly because of their own egos at root.
Surely it's fine that moaning about how doing design before writing code is boring, a waste of time (because it's "just documentation that won't apply at the end of the project anyway"), or beneath them (it's for people who aren't smart enough to write code). I've heard variations on all of these in person, and seen them in comments here on HN.
Gunning for the big glory of "saving the company" by re-writing the whole thing from scratch in Fancy New Language/Framework X certainly has nothing to do with it, right? This happens more often than some might care to admit.
Engaging in ego-stroking/pissing contests about CS trivia and minutiae instead of focusing on the broader engineering tasks and problems at hands is blame-free, yes?
This industry is absolutely packed with very smart people who, from an engineering perspective, fall quite short, mostly because of their own egos at root.
Two years later, they get breached, 10 million unhashed passwords leaked, and yet they have such a stranglehold on the market that the breach barely affects their bottom line.
Compare that with say, the aerospace engineering industry, where putting out a faulty airplane that crashes, brings with it lawsuits, damages from victims, huge hikes in insurance premiums, and higher demand from consumers for your competitors' models.