Software engineering 101

Software engineering 101

Dr. Olivier Coudert

I

I was prompted to write that post after days (weeks) of frustration working with a new company. I thought that would capture the essence of what software development should be.

Software engineering 101

Dr. Olivier Coudert



Software engineering 101
Olivier Coudert

I was prompted to write that post after days (weeks) of frustration working with a new company. I thought that would capture the essence of what software development should be.

A bit of context first.

There are people out there whose motto is “we make money selling hardware, not software”. Because of this, they are misled to believe that software is just an addendum to their hardware, and therefore software does not deserve the attention received in “real” software companies. In the same line of their thinking, software bugs can be “patched”, so we shouldn’t invest as much into it.

How delusional these people are.

Just to pick one example close to our field, remember the debacle of Altera in the early 2000’s? At the time, they were #1 in the FPGA market. Then they choose to release a half-cooked, mostly untested release of their new place-and-route software. The damn thing just didn’t work, to the point that some Altera sales people recommended their own customers to hold on the old release, or to just temporarily switch to Xilinx… 18 months later, Altera lost its top stop to Xilinx, which Xilinx still owns today.

Other examples of hardware-selling companies that missed the point on software are legions in the telecom industry: Motorola, Nokia, Research In Motion, for the most obvious ones. How about the blasting success of Apple’s iPad with its iOS, still leading the market despite the many contenders running some flavors of Android, without even mentioning Microsoft with its Surface tablet.

Do I need to say more? It’s not because your primary products is hardware that you can afford to overlook software. You might give your software away, you might have less than 100 users, but your software still requires the same attention as if it was the main source of your revenue, or if you had millions of users. Trying to get away with poor software will kill your business, every single time.
Software engineering relies on the following practicalities:

• •    Testing

1. o    Code that you cannot test is useless. Design code so that it can be tested.
2. o    Code that is not tested is just a time bomb waiting to explode. “Developing code” really means writing code and writing tests.
3. o    Unit test every time you can (see more here). This forces developers to flush out every single detail of an API and its implementation. And unit tests run fast.

• •    API design. Designing a good API is difficult (see more here). Do spend the time to get it right. Else you’ll pay a hefty price later.
• •    Automation. Building, testing, versioning, code merging, all must be automated. Developers should just type a single command line and be done with it. Anything else is time consuming and error-prone.
• •    Quality measurement. This covers a lot of aspects, but enough to say that you can only improve what you can measure –speed, memory usage, robustness, coverage, etc.
• •    Uniformity. Do have one coding style. Do have a unique way of building your software and testing it. This way you factorize the effort and increase efficiency.
• •    Short turn-around-time. You want a fast development cycle? Then make your build and testing as fast as you can, so that developers can write, test, and commit code in small, manageable increments. Do use parallel build on a grid.

Do use pre-compiled libraries. But don’t compromise automation when doing so.

That’s it. No fancy theories, no pompous methodologies, just down-to-earth, self-explanatory practices. Or so I wish.

{loadposition content-related}