We all admit that this happens, but we never stop to think about why it happens. Let me put forth a hypothesis - deadlineitis! Programmers have been bamboozled into believing that software development should be an engineering discipline. While there are some things that engineering can offer to software development, there is much that the engineering discipline cannot "solve" for software development. Let me defend this. "Engineering" is the discipline that says we can build massive structures by applying known smaller structures, that have mathematical descriptions which can be added together to present a mathematical model of the desired structure. In software development, so-called "software engineers" repeatedly encounter instances of where there is NO smaller software structure - merely methods that "almost" work, methods which are "not quite" what is required, or even a lack of smaller structures that even come close to what is required. Add to this that combining all these "iffy" structures together leads to coupling problems - emergent behavior unanticipated by anybody. (And if you are looking for mathematical precision, well, good luck with that.) So software development winds up being a series of "experiments" - tweaking prior structures, and even developing your own structures, with the "requirements" for the structures being imprecise and unclear. Under "project management", this is seldom, if ever, accounted for, because, like so much other stuff, the concept of "project management" was imported into the domain of software development from the engineering disciplines. Imagine, if you will, the plight of an bridge engineer if he had to redefine what a "truss" was multiple times during the life of the project. It's relatively easy to put together a bunch of well-known structures to complete a much larger structure on time, on budget, and safe (yet even then we have major cost overruns and major delays, and even failures of the final product). The problem with software is the fact that compared to "physical" products, there is no conceptual limit to what an individual piece of software might be. You want it to do A, B and C. Why not? Could you get it to do D as well? No problem. How about E and F? Well, that may strain our resources a bit. Oh, we can't have that. How about if we eliminate C and D - could we get E and F for the same cost and in the same time? And on and on it goes. So what happens when a software developer has to develop on of these base widgets, or t

Formality seldom survives the first missed deadline. Software engineering is not a programmer's term; it is a manager's term.

Actually, upgrades to operating systems don't have to be the pain that you assume they are. Since you are running Windows 7, I would get virtualization software (I use VMWare Workstation), and create a virtual Windows 8 machine. And then you'll realize immediately why Microsoft went to 8.1 almost immediately. And then you can try Windows 10. I like 8.1, and dislike Windows 10 after running it on a virtual machine for 4 months. Therefore, I shutdown 10, and never use it except once in awhile to pick up the updates. Virtual is the way to go - you can get comfortable with a new operating system, without mucking around with your main OS, and if you like the update, you can do one of two things - install the new OS on over your main OS, or continue using your main OS just to bring up a virtual machine of your new OS.

The alien artifacts are in area 51, not the pentagon. They were in the pentagon, but then the "plane" hit the building ...

*IF* the calculations for aeroelasticity (the actual cause of the disaster) were "Engineering 101", as you claim, then the blame does not rest solely on the hands of the civil engineer who designed the bridge (Leon Moisseiff, in case you are interested) but in the engineering team that accepted his design and the inspectors charged with ensuring that the work was done correctly. (The bridge did NOT gain the nickname "Galloping Gertie" was not given after completion - it was given by the construction crew.) Aeroelastic models only came into existence in the twenties and thirties, and surprise, surprise, they came from the new science of aerodynamics, with research being almost totally applied to the building of airplanes. Much as you would like, aeroelasticity did not become part of "Engineering 101" until after the Tacoma Narrows fiasco, and that bridge collapse was one of if not the prime motivator for aeroelasticity becoming part of Engineering 101. As for "Would you drive over one of his bridges on the way to work every day, knowing he didn't bother to make sure nothing would go wrong?", I really hate to quote Donald Rumsfeld, but it is appropriate. He said, "Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones." Discovering those "unknown unknowns" is the history of engineering

In my humble opinion, there are three types of managers. The first type has been promoted to his level of incompetence, a la Peter Principle, eg, the crackerjack project manager who is a bumbler as a department head. The second type wants to promulgate complexity, in order to make himself look better - the classic pointy haired boss in Dilbert. The third type, very rare, but responsible for the bulk of any organization's success, is the one who knows what needs to be done, understands that he cannot do it alone, finds the best people for the jobs that he creates, and let's them go to work, and clears roadblocks.

Get a hold of yourself. This woman would not have 2) Open the comma delimited file in Notepad. 3)Do a fin/replace on a few broken values. 4) Save the file 5) open it in Excel and change the column order 6) Delete several rows that are 'gibberish'. 7) Add a few rows that have to be there for it to work properly IF SHE DID NOT THINK THAT SHE HAD TO DO IT!!!! The people who know the least about a process are programmers and analysts who do not bother to ask the end user what they do. I'd wager dollars to doughnuts that the majority of formal processes that exist in organizations bear little if any relation to the actual process that gets the task done. Any programmer and/or analyst who believes a manager who says "Here is the formal process. This is the way that we do things." deserves to be frustrated - he/she is not living in the real world.