Most architects, me included, are passionate about their work. They follow the state-of-the-art of their profession, they think about refactoring topics to improve the architecture under their responsibility etc. And the point is, they do these without anybody telling them to do so. On the contrary, most architects will negotiate with the management to be able to access more resources on architecture such as books, conferences; or to be able to implement the refactoring ideas. This is a good example of intrinsic motivation.

This context prepares us, the passionate architects, for a mistake: we assume that everybody is passionate about architecture, yet, in fact, people have different sources of motivation. So we do not invest time in aligning with other stakeholders, and we end up with a bad architecture or a failed change initiative. Continue reading Levels of aligning with people →

Grady Booch defined software architecture as everything costly to change. This implies that the software includes some parts that are not so costly to change. However, if the project doesn’t have any buffer for changes, or when a “first-time right” culture is adopted, everything becomes costly to change, as every change will need escalation and approval, thus everything will become “architectural”. Continue reading The critical role of changes →

Last week, I was at a multicore event, and some presentations reminded me of my MS thesis work back in 2008-2010. In this post, I’d like to provide material produced during my MS thesis work with my professors Arda Yurdakul and Alper Sen with a short introduction.

The work was about introducing the HW-in-the-Loop (HiL) method to the HW-SW co-design domain. HiL is about integrating virtual (simulated) environments with real environments to enable useful scenarios such as testing virtual models under development on real test beds, testing real devices with virtual test beds etc. Continue reading HW-in-the-Loop with SystemC →

A beginning is the time for taking the most delicate care that the balances are correct.
— Frank Herbert, Dune

Towards the end of the implementation phase of the software, the moment of truth for the architecture arrives. All weak parts of the architecture start showing themselves: the integrated components do not play together, NFRs are not satisfied, maintenance costs explode, tests are hard to execute and bring limited meaningful results and so on. Continue reading The moment of the architect →

When I was implementing my first driver at work, I was a bit surprised that the OS (WinCE) wasn’t providing a mechanism for notifying the application from the driver. Of course, I cleverly used a named event to accommodate for the missing “feature” of the OS.

And of course, this was wrong. And I wasn’t alone in my mistake. I saw other colleagues, as well as people on the web (here is an example from Stackoverflow) trying to do the same. So I think this is a good mistake to share, especially for rookies in driver development. Continue reading Rookie mistake: kernel to user-space notification →

In contrast to application software, embedded software generally have multi-threaded designs. The main driving factor behind this is a complex environment in which multiple events are occurring in parallel: user(s), inputs from peripherals or network etc. Drivers in particular are also affected in this context, maybe even more so as because they may be servicing multiple applications and HW components simultaneously. In addition, the driver models of OSs are generally not very specific about threading models, therefore the drivers become passive servers of multi-threaded and sometimes buggy clients, which makes it hard to foresee which function of the driver will be called when.

So, this context prepares almost all conditions for several race conditions. In my experience, most race conditions are caused by a few common situations, and in this post I’d like to summarize my knowledge about them. Continue reading Common race conditions in drivers →

In this post I’d like to reuse one of my previously written pieces. I wrote it as part of a take-home exam for a software architect training program at Siemens^[1]SSWA, Senior Software Architect training program. I believe ;-) the copyright is still with me.. We were asked to choose and elaborate on a quote about “late phases”, i.e. the stuff that happens to your software after it is released.

The thing the ecologically illiterate don’t realize about an ecosystem is that it’s a system. A system! A system maintains a certain fluid stability that can be destroyed by a misstep in just one niche. A system has order, a flowing from point to point. If something dams the flow, order collapses. The untrained might miss that collapse until it was too late. That’s why the highest function of ecology is the understanding of consequences.
— Pardot Kynes in “Appendix I: The Ecology of Dune”, Frank Herbert, Dune Continue reading Late phases and ecology →

The Pareto principle (aka. the 80/20 rule), which tells us that at 20% of the cost we can realize 80% of the value, is applied widely and IMHO wisely in SW development.

In this post, I’d like to direct your attention to the remaining 20% of the value. Let us define  a “simple” SW release as a release for which you don’t need to take into account aspects like: Continue reading The boring part of the 80/20 rule →

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 →