While many companies will nowadays pride themselves on their platforms, few actually scrutinize the whole idea: “Do we need a platform at all?” I guess most seasoned developers will answer this question with a resounding yes, although I’d think this has some caveats, that might tip a decision against a platform. In this article we’ll have a look at some of the most important things to consider, when deciding, wether building a platform is a good idea, and how to tip the scales in favor of a platform. These are technical as well as organisational issues – mostly the latter.
Note that I’ll mostly talk about rewriting the software in question. As stated in the last article it should in many cases be next to impossible to evolve a lower tier platform into a Gen 2/3 platform – if this does not apply to your software, good for you, you’ve obviously done your homework and had a tremendous amount of foresight when making your first implementation. For the rest of us, who only have the knowledge of hindsight: When I’m talking about a rewrite, remember, that you should always use all means at your disposal to get your work done – if that means porting from older code and making a couple of refactorings to get the code testable, then so be it.
Now, let’s dive into the reasons that might speak against rewriting major parts of your code to create a platform.
Platform Overhead
A platform lives from the abstractions it provides to create common functionality that is easily portable. As such it will inevitably introduce some overhead – few abstractions are free, neither in terms of MCU flash, nor performance nor battery life (if that is a concern). If we manage to leverage compiletime features of modern languages we might be able to alleviate some of these problems, but they will not go away and we have to face the fact that a platform might be more than our hardware can handle. E.g. if we’re looking at a humble 8 Bit AVR based MCU we will hit hardwarelimits very soon. Depending on the complexity of our usecase even this tiny MCUs might actually warrant a platform based approach, provided we can reap the benefits a good platform provides.
Painpoints
I’d wager most developers will state that their current codebase could need a rewrite, and this is quite frankly more a sign that these developers are still improving their skillset and don’t stagnate, than that there is an urgend need of a rewrite. It also at least indicates, that the developers have identified weak spots in the current architecture of the product, that might not be easily adressable without major changes. Assess these painpoints and try to estimate the costs they cause, compared to a hypothetical optimal solution. To do this, try to answer the following questions:
- How does the current architecture influence the time, development of a feature takes?
- To what degree do changes in one part of the software “ripple” through to other parts of the software, i.e.: How many parts of the software need to be tested after an average chenge?
- How much of the tests can be automated (or are already automated)?
- How resilient is the architecture to change?
- How long does it take to get a new developer to a level where he/she can contribute to the software without breaking too much?
Sadly, there is no metric that will give you a clear answer to the question if a platform is worth the effort – there are too many variables involved. However, the above questions can serve as a good startingpoint for an in depth discussion as to the worthwileness of a platform.
Lack of process
If we answered the above questions dutifully and have decided, that a platform would be a wise choice, we should ask ourselves if we have the processes in place that enable us to have a fighting chance at succeding.
While the software most software (even generally well crafted software) will have lots of warts, we must acknowledge, that it embodies a lot of business knowledge – depending on the age of the software, it might even contain knowledge that is no longer present within the company. This will obviously pose a risk, if a rewrite/”plattformification”, as we might end up not implementing features that a relevant for a larger part of our userbase. This is true in most cases, even if the problem domain is well understood in the development team, chances are, that there are at least some hidden functions.
Note that the severity of this risk is a direct function of the process maturity of your company. Companies, that sport a mature requirements and documentation process should be able to minimize the risk. I’d urge everybody to do a thorough and honest assessment here – if there is a lot of informal knowledge around, the company is probably better off to – at least – postpone a rewrite until all the homework is done.
Its not a feature
We have to be aware of the fact, that a platform is a tool we, as engineers use, to get our work done, at least in most cases. A well implemented platform will help us to produce more products at a higher qualitiylevel in a shorter amount of time. However, these metrics are often hard to grasp for product managers, that primarily want happy customers (i.e. customers that have their usecase served). A PM will not be able to “sell” a platform to a customer – indeed I’ve worked with PMs that, while capable – struggled with understanding the benefits a platform can provide (they usually switched between “this is a silver bullet for all our problems” and “this will just slow us down and is not worthwile”). Coupled with the time investment needed create a platform that – at least – adresses some usecases creating a platform can be a a bitter pill to swallow for the non technical folks.
We, the technical people have to tread carefully here: It is our responsibility to explain what a platform can (and most importantly can not) do. We must avoid to build up high hopes, that stem from a lack of understanding, lest we end up in a situation, where everybody will lose: The engineering team will lose credibility, the customers will be unhappy because the promises given to them will not be fulfilled, product management will have to bear the wrath of the customers and management will feel, that the project spiralled out of control and burned a lot of money with little to show for it.
Organisational Constraints
As I’ve mentioned in the previous post, a modern firmwareplatform is nearly as much an organisational topic as it is a technical topic, so it is important to know/evaluate wether your organisation is able to support the development of the platform you plan to build. Even if you attempt to build a lower tier platform you’ll have to deal with some organisational topics, such as:
- Upfront investment (time): Generally speaking an R&D department will (and should!) spend a sizeable amount of time on building the basics of a platform. During this time nothing that is visible to a lot of stakeholders will be produced. This time is all about getting the core architecture right, i.e. answering questions like:
- “Who communicates with whom?”
- “How does the communication take place?”
- “Where do we anticipate future extensions?”
- “How do we want to test this product?”
- Upfront investment (money): The time that is spent in the last point obviously translates to spent money. There might be additional costs involved, such as those that arise when buying eval boards for new MCUs or similar.
- Opportunity costs: Even if we don’t consider the above two points as critical for the project itself (we might have a long term release plan and a very generous budget) few R&D departments operate in isolation. In reality there’s always a current product that is sold to pay the bills. Investing in a new platform will inevitably commit resources to a new project, that would otherwise be available to implement new features.
No matter how seducing the possibility might be for a greenfield approach (and anybody, that does not aim at least at a Gen 2 platform nowadays should – IMHO – not bother at all), the above issues have to be sorted out with the relevant stakeholdes, i.e. management. Especially for the upfront investement part we need buy-in from management, as we absolutely must not take shortcuts here, lest we compromise the design from the start, which will haunt us for most of the life of the platform.
With respects to the opportunity costs – this is something management is usually far more aware of than R&D, so this is actually more of a case of R&D getting to grips with reality and doing a good estimation of the resources needed for maintenance efforts of the current product – of course R&D will have to consult with product management to come up with a strategy for the current products, that limits the amount of maintenance, while still keeping customers happy.
Inertia of the current product
We have to be aware, that, unless we’re doing something completely new, that does not have a predecessor, we have to put up with the fact, that our current product has a lot of inertia – it will probably be established on the market with a given featureset, that might be – depending on the maturity/age of the product – quite large. Our customers rely on that featureset, meaning, that any new product, no matter it’s genesis, will have to – at least – bring the very same featureset to the table and then some. Our customers will usually not care about a fancy platform in the background, they want their problems solved, and in that respect a platform is just a means to an end. If it can not (yet) solve the problem it will – obviously – be of limited/no use for them.
In the end this can lead to a deathmarch for the team developing the new product/platform, as they race to meet the full featureset of the established product, with potentially desastrous outcome (be it burned out developers, compromised quality or – likely – both). In order to avoid this and to also avoid not meeting the expectations R&D should attempt a phased replacement of the existing product – again this can only be done if product management and upper management buy into the idea. From an R&D perspective we have to consider the following points:
- We should get the buy-in from product management to build a minimum viable product that solves a meaningful subset of our customers problems (i.e. the core functionality). This helps to reduce time to market and get feedback faster, while also establishing the platform as a product that generates revenue instead of only producing costs. We’ll also be able to slowly replace our existing legacy product in the market, which will enable us slowly shift resources from the legacy product to the new product/platform.
- At the same time we must be able to supply our PM with a realistic roadmap to get from said subset to a full-featured product, as they’ll have to be able to answer this question to upper management and to the market.
TL;DR
- Make sure you build your platform for the right reasons
- Get buy-in from your stakeholders
- Plan resources to support your current product
Image by Daria Nepriakhina