Programmers should not be allowed to call themselves engineers
There is one thing the Canadian government has done right, at least in the field of computer programming, is banning computer programmers to call themselves engineers. In Canada, engineers must be certified. And if you are not certified, regardless of your qualification, you are not an engineer.
Normally, I’m not for more government involvement as this can only add more bureaucracy. But in this case, I do agree, not because computer programmers are idiots and can’t be engineers, but because there are simply too many people in this field that should be thrown out the window from a 120-story building, or hanged. Ok, not that drastic a measure, but still, you get the point.
To be an engineer, you need to have a scientific background, and a systematic approach to the works. The requirements and specifications of each project must have gone through an elaborate thought process to consider all cases and scenarios. A professor of mine at the McGill University has always said, you need to think like an engineer.
If you have done enough software projects, you must have figured out the pattern already. Programmers would sit down and start coding, before even understanding the requirements, let alone specifying how the system should work.
An architect-plus-civil-engineer friend once said to me, you guys are a bunch of sloppy people with sloppy process, and you dare calling it engineering. I don’t blame him calling me (us, I’d say) sloppy, and I agree, we are fucking sloppy in project requirements and specifications. And as a member of the computer programming field, I have always been amazed by our peers who are proud of this sloppy process.
This is not to say that there are no building collapse due to bad engineering or design. There are a lot of examples. But looking at the success rate of software projects, we have nothing to snide at them. Of all of the technical fields in this world, we probably have the worst track records in terms of success rate.
The amazing thing though, is with our peer’s attitude towards a more systematic, more scientific methodology in the process to make this worth calling software engineering. Not only do we not try to improve our process, but we sneer at the best practices. You are laughed at, if you even dare to think about it.
Lately, working on a project with someone with many years of experiences, he keeps telling everyone, at every possible occasion that, spending two weeks to write specifications of a software project is a waste of time. And in fact, 99% of software projects failed (I don’t know where he got this number) because people spend time writing specs rather than writing code. So, according to his methodology, we should just sit down and write code, and patch it along the way. And there is no need to try to work out the project schedule either, because this is also a waste of time. It’s done when it’s done. He is so adamant about not writing any document that it’s impossible to reason with.
Detailed requirements and specifications are sine qua non to team work. Systematic thought process is the only way to full consideration of all possible scenarios. Researches after researches have shown that the following are the major causes of software project failure:
- Lack of clear requirements and specifications
- Lack of clear objectives and goals
- Lack of realistic schedule
Effective management, technical skills, sufficient budget and resources, communication, etc, are all secondary factors. And here, he is putting up every obstacle possible to not have any of these critical success factors. In a previous post, I had said that project team is extremely important. And when we have team members with this kind of attitude, it is worrisome.
Writing detailed specifications does not mean we know everything from the beginning, and that we don’t need to do research and prototyping on certain components. Far from it, writing specifications is a thought process that forces us to think through every edge case, and have a review process to catch mistakes early on. That does not prevent us from writing code to test out certain ideas or algorithms. In fact, engineers in every other field do the same thing. Civil engineers have to prototype and model certain components to make sure that the building can sustain certain magnitude of earthquake. Mechanical engineers have to model aerodynamic behavior in a wind tunnel to understand certain aspect, etc. But in the end, they always have to work on detailed design and specifications and go through a review and approval process. Yet, how can a computer programmer, who obviously has not been familiarized with any scientific methodology in his life, be so arrogant to say, “trust me, you don’t need to know, and I’ll tell you when it’s done”? This is sheer arrogance, and down right ignorance and idiocy.
It is no wonder the success rate of software projects is abysmal, while we continue to hang on to our own arrogance, ignorance and idiocy. That’s why I agree that programmers should not be allowed to call themselves engineers. We are just a motley crowd of amateurs, not engineers.