Implementation by Feature and Embedded Systems Issues


I've been working with some companies who do hardware/software systems. Most often, they have some embedded code too, just to make life interesting. To be honest, I don't know how to do implementation by feature for a whole brand new system. Here's what I've been suggesting:

  • Prototype the software architecture as early as possible, even if it's just one path through the architecture, even if everything isn't set up into neat little components. Chances are good the hardware doesn't exist yet, but if it does (even a prototype), proto the software onto the hardware and see what happens.
  • Make as few components as possible. This is a variation on the KISS principle. Sometimes, it's easy to break things down into a picture with a gazillion components, but that makes it harder to write and integrate the code.
  • If you must implement by component, integrate by feature.
  • Develop automated unit tests, preferably using test-driven techniques, so you really don't write more code than you need.
  • Be ready to integrate a few things at a time, so you move towards continuous integration. Whatever you do, arrange things so you're not doing big-bang integration of the hardware, software, firmware, whatever at the end.

Do you have any suggestions/ideas? In my experience, once a system is built, it's relatively easy to add pieces implementing by feature. But it's much harder when defining and building a new system from scratch to implement by feature.

4 thoughts on “Implementation by Feature and Embedded Systems Issues”

  1. Vladislav Bogomolny

    I would like to add one point,
    There are cases when hardware is responsible for breaking your code.
    I suggest not to spend too much time on workaround of obvious hardware problem. Report the problem to hardware manufacturer and proceed with you project. You can count that hardware problems will be solved.

  2. All very good principles, also very reminiscent of Scrum. Similiar to the KISS, I would recommend a YAGNI approach (You Ain’t Gonna Need It) to architecture – basically just architect for the things that you absolutely need – don’t necessarily consider feature extensions, reuse, etc – as there is no guarantee that you will need this in the future.

  3. Madeline Thimmes

    I purchased the book “Getting Things Done” by David Allen. It changed my life. You might enjoy it seeing how you are in the mood to organize.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: