In school we are taught how the programming process works, by people who have not had to produce real software, and have no idea how the real works. Here are some real wold examples of how people actually development software.
The customer calls in. He is in a panic. There is a major problem with the program with the software. He needs it to be fixed right now.
Management panics. Management makes you panic. 80 hours work weeks are called for. Finally after several all nighters, the fix goes out.
And another customer calls in.
If you’re lucky customers call in one at a time. If you’re not then a big customer calls in. A panic project starts to fix his problem. A bigger customer calls in with a bigger problem. Work for the first customer is suspended, while you work on the problem for the bigger customer. And hope during that time that an even bigger customer doesn’t find a problem.
So you want me to rush this job for you ahead of the rush job that I’m rushing to complete now?
Software engineer to customer: What do you want?
Customer: A process automation tool.
Software Engineer: Can you describe it a bit more?
Customer: You know – a process automation tool Everyone knows what that is.
Software Engineer: Can you give me some requirements?
Customer: It’s a process automation tool.
So you write the tool as best as you can.
Customer: That’s not what a wanted. This part is wrong!
Software engineer: Can you explain better what you want?
Customer: You know. It’s a process automation tool.
You modify the program.
Customer: That’s not what a wanted. This part is wrong!
This process is repeated until the programmer runs out of patience or the customer runs out of money. Every once in a while it is because the program works and the customer stops telling you what’s wrong.
You have version 4.0 and management wants a new and updated version with lots of new features. “Great,” you say. “What does 4.0 do?”
“Oh, we didn't bother to write requirements for that. It does the same thing as Version 3.0, but with added features.”
“Did you document those features?”
“No.”
“Did you write requirements for Version 3.0?”
“No, but 3.0 does the same thing as Version 2.0, but with added features.”
You may see a pattern here. So you have to figure what Version 4.0 does, and that requires researching Version 3.0, then Version 2.0, then Version 1.0 and so on. Simply getting coherent requirements is a major step. And that’s before you approach the mess of code that implements them.
You get a brand new device and your job is to make it do a simple task. You write a simple program. It fails. The hardware is broken.
You read the documentation and find there is another way to make this complex device work, so you try a different approach. It fails. This is repeated until out of the ten different ways of doing the simple thing you want to do, you find nine that don’t work and one that does.
The system is down. Lots of people depend on the system and stand to lose millions of dollars every day that it stays down. The programmer who wrote it has left the company and he didn’t believe in documenting his code, so there are no design documents or even comments in the code. His decision to reinvent the wheel means his program contains a lot of complex code that replaces simple, standard libraries.
That’s when you’re called in. If you’re smart, you’ll negotiate a bonus or a pay raise when you encounter this sort of thing. In my case, I was not secure in my job, so I didn’t. I ploughed through 80-hour weeks to go through the legacy code to figure out what it did. I never got it totally working. There were still some errors that occurred when we ran it, but we programmed around those with automatic fixes.
We got the system running. I then wrote up a document that described the things we should do so this never happened again. As far as I know that document was never read by management.