I'm a software engineer. My official capacity is analogous to the job Google and Microsoft (and others) lovingly title Software Development Engineer in Test, or SDET. If you ask a random sample of "Software Engineers" for a description of their job, there will be a huge disparity in what they will tell you. It's not that everybody does wildly different things, it's simply that nobody really agrees upon what engineering of software entails.
There are many schools of thought on the topic; waterfall, agile, test driven development, x driven development, etc. But as you may notice in the names of all of these methodologies, they are all styles of "development", not engineering. As a self-described Software Engineer, I am guilty of perpetuating yet another opinion of what it means. To sum up my understanding of it:
Software engineering is using the best tools at hand to achieve the necessary goals.
Notice that I made no mention of software, programming, engineering, or anything else. I have a strong opinion on the subject that sometimes the best option for a Software Engineer is to use a credit card to buy a COTS software package. Sometimes the necessary goals don't make sense, so words are required to explain that fact. Only after exhausting all other options should one consider the insane practice of writing code. Programming takes time. It takes a huge amount of mental effort to get into the mindset required to think about what is necessary to produce the desired product. Once one is in the zone, it is an extremely brittle state. I digress.
Back to the main point, software engineering is using the tools at hand. For some people the best tool is not their mind. When another person has already made the effort you may need to make, why reinvent the wheel? The answer is unfortunately complex. To paraphrase and make the language g-rated:
Other wheels are full of holes, only work on one type of road, and will sometimes explode if you put them on the wrong car.
Mixed metaphors aside, we keep on engineering because the humans before us have done it improperly.
What sets apart engineers is that they can design a system within a set of parameters. They prove mathematically that the bridge can withstand a magnitude 7 earthquake for 5 minutes. They prove mathematically that the skyscraper can withstand a 70-mph wind at the 90th floor. They prove mathematically.
I have never seen a software engineer offer up a formal proof for their code. The closest things we see in software are tests; poorly written at times, and often only covering 50% or less of the actual code in question.
There are movements to improve code coverage of tests. There are open source projects which are run by idealists. The sad state of the industry however is that the projects which need the tests are also the ones which never get them. A
developer *ahem* software engineer will start a project and say to their team "no compromises this time" and write the first few tests, perhaps based on the requirements or a spec. Weeks or months pass and a deadline is missed, and the manager or other stakeholder decrees there is no time for 100% code coverage. Only code which is reused will be tested. Another deadline is missed, and management declares that only library code will be tested. You get the point.
It is the Engineer's job to stand up to management in this instance and plead for their formal proof's worth. It is the Engineer's job to stand by the quality of their product. It is the Engineer's job because the Engineer is the one with the education in engineering.
I propose an addendum to my earlier definition:
A software engineer is a programmer who can provide proof that the code which they produce works.
1.^ Assuming they all work at different companies[2 (yes, this is a recursive footnote)].
2.^ Possibly even the same company.
3.^ Except for this tragedy, but they learned from it and use it as a standard model now.
4.^ Except for cryptographers. They are awesome.
6.^ Yeah, right. We know it's not a formal proof. Let's ask a Software Engineer to write a mathematical proof for their algorithm.
7.^ And don't just write all your tests to return true. I mean true code coverage.
Subscribe to Greg Cochard
Get the latest posts delivered right to your inbox