The world is increasingly pushing us to produce software faster, at lower cost, with smaller and less experienced teams. We have to enable ourselves to do it better and faster. This pressure also causes teams to focus on the next milestone instead of the long-term realities of the project.
So the primary question is: what systems, techniques, and processes can we put into place to produce higher quality software with lower effort?
We want:
- to increase our personal effectiveness
- get feedback faster
- prevent bugs before they get checked in or reviewed by others
- prevent bugs from reaching the customer
- to quickly and easily respond to changing requirements
- to be able to produce higher quality software with smaller teams, allowing us to work more flexibly in today’s world
What are some ways we can do this?
- Design embedded systems to support change
- Build embedded systems to support testing automation
- Leverage tooling to catch issues as early as possible
- Creating reusable software increases our speed in the future
Related
- Development teams tend to focus on the next milestone, not the long-term
- Automating Away the Fun Parts – this pressure, combined with the use of AI tools, seems to be reducing our engagement with the parts of this job we actually like the most
References
- Niklaus Wirth
Time pressure is probably the foremost reason behind the emergence of bulky software. The time pressure that designers endure discourages careful planning. It also discourages improving acceptable solutions; instead, it encourages quickly conceived software additions and corrections. Time pressure gradually corrupts an engineer’s standard of quality and perfection. It has a detrimental effect on people as well as products.
- Reusable Firmware Development by Jacob Beningo
When it comes to product development, the single constant in the universe is that the development either needs to be done yesterday or by some not-so-distant future date.
- Patterns in the Machine : A Software Engineering Guide to Embedded Development by John Taylor and Wayne Taylor
But referring to “traditional” embedded software projects may be the wrong word to use. Embedded software isn’t developed the way it is because of tradition; rather, it is often developed this way out of a sense of desperation
- Frequently Forgotten Fundamental Facts about Software Engineering by Robert Glass, IEEE Software, May/June 2001
ES3. Most software estimates are made, according to several researchers, by either upper management or marketing, not by the people who will build the software or by their managers. Therefore, the wrong people are doing estimation
ES7. Pressure to achieve estimation targets is common and tends to cause programmers to skip good software process. This constitutes an absurd result done for an absurd reason.