In SW development, we have a frequently recurring theme: if we put in more time/effort now, it will save us from spending additional effort and time in the future. This can apply to refactoring, testing, build and integration, source control, static code analysis, training, code/architecture reviews, requirements engineering, design documentation etc. Once, a manager interrupted my refactoring presentation with a remark mocking this theme, and caused me to lose some momentum. Continue reading ROI is not enough
Monthly Archives: December 2016
DIP & Vitamins
I came across an interesting parallel between biology and software.
Dependency inversion principle (DIP) is key to creating portable software. The essence of this principle is defining interfaces top-down based on the needs of the software. This has the consequence of putting the requirement first instead of the underlying implementation. So, we become user-oriented instead of technology-oriented and hopefully succeed. Continue reading DIP & Vitamins
Checklist for embedded communication
Embedded systems – being embedded – talk to their environment quite intensively. And nowadays, as system complexity has increased, the environment doesn’t only consist of simple sensors and actuators which one could talk to via ADCs, DACs, PWMs or GPIOs; but of more complex peripherals to which the embedded systems talks via some protocols such as CAN, I2C/SMBus, SPI, EIA-232/422/485 and so on.[1]I can recommend John Catsoulis’ book Designing Embedded Systems for a walkthrough of these interfaces.
These protocols provide the design for the physical layer and some data link control layer. So, one has to implement his own design for the remaining layers if they are needed by the specific requirements. In my experience, development teams tend to underestimate the requirements on the protocols[2]“It’s just two microcontrollers talking.”, so high costs and delays occur when protocol designs – which are architectural – are being amended in later phases of projects. Continue reading Checklist for embedded communication
Footnotes
| ↑1 | I can recommend John Catsoulis’ book Designing Embedded Systems for a walkthrough of these interfaces. |
|---|---|
| ↑2 | “It’s just two microcontrollers talking.” |
Key architectural skill: conquering code without understanding every detail
Climb the mountain just a little bit to test that it’s a mountain. From the top of the mountain, you cannot see the mountain.
— Frank Herbert, Dune
Once, I was working with a colleague who was responsible for the storage subsystem. As typical in most cases, instead of developing the storage hardware, drivers and the file system, we reused such components as OTS (off-the-shelf) and implemented the additional requirements on our own. When something in the storage subsystem didn’t work as expected (e.g. bugs, insufficient performance), we had to sit down with my colleague and look at the components (reused ones as well as ours). And I often heard the argument that in order to be able to make a proper analysis he had to study the components in detail. However this would cause us to miss the release deadline, and kill our development budget. Continue reading Key architectural skill: conquering code without understanding every detail
Concerned about the lack of documentation in your project? You are already (over)doing it
If you are in a SW project which lacks proper documentation, most probably you are already over-documenting.
Documentation is communication, and communication is constantly needed throughout the development of a SW: Continue reading Concerned about the lack of documentation in your project? You are already (over)doing it