We're working on a new firmware for our new V2 device. The company has an older V1 firmware (and hardware). Hardwares are similar to each other (but there are some differences) so basically we could use V1 firmware with "some" modifications. Unfortunately V1 firmware is spaghetti code. We need to support both hardware including new features, so code should be maintainable.

We've tried to create a backlog with small stories. Each story would show a new working function to the user while it extracts out a reusable part of V1 code to a library project and use it in V2. It would have been kept both V1 and V2 firmwares always releasable and we would have been able to show a working demo early (with limited functionality at first).

In time it turned out that management expects that it will be a short project (since hws are similar) and they suggest another approach: move everything to the library project and modify only those parts which are different. This approach seems riskier because we won't be able to demonstrate any progress (the first demo will be later, it's rather all or nothing, every module has to work more or less for the first demo) and I guess it could lead to unpredictable bug fixing.

What should I take into account before deciding between the two approaches? Is there a third one?

  • 2
    "move everything to the library project and modify only those parts which are different" Are you sure you can do that? Because poorly designed code is usually close to impossible to "modify only those parts which are different" – Euphoric Mar 20 '14 at 7:54
  • 3
    What do you mean, "spaghetti code"? It sounds a bit subjective. This problem sounds too broad/opinion based. There are entire books on this subject, for example, "Working Effectively with Legacy Code" – Dave Hillier Mar 20 '14 at 8:35
  • 1
    @DaveHillier: From Wikipedia (the first link in a google search): "Spaghetti code is a pejorative term for source code that has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow is conceptually like a bowl of spaghetti, i.e. twisted and tangled." – Michael Shaw Mar 20 '14 at 9:15
  • 1
    Possible duplicate: programmers.stackexchange.com/questions/155488/… – Dave Hillier Mar 20 '14 at 9:30
  • 1
    @user124017 perhaps you could edit your question to include a couple of examples of this? – Dave Hillier Mar 20 '14 at 20:32

Is there a third one?

If the V2 hardware is "downward compatible" to some degree to the V1 hardware, there might be. Is there a chance to get the V1 firmware running an the V2 hardware with minimal effort, supporting none of the new V2 features? Maybe by adding some "compatibility layer" to the unmodified V1 code? If that's the case, I suggest you try this first - with a limited time frame. If that approach fails, you will have all arguments at your hands to tell your management why your cherry-picking approach will work better.

And if the "take V1 firmware as is" approach works, your management is probably right. The new V2 features have to be added after the "port", and you may have to live with some spaghetti code longer than you like, but instead of refactoring all the code (with the chance of introducing new bugs), you can refactor the pieces you have to change, but not more (which has a much better economic).

Another factor is if you try to create two codebases (for V1 and V2 hardware), which you have to maintain both in the future, or if your new code base for the V2 hardware shall also be able to handle the V1 device (and you want only to have one codebase to maintain or both device versions). If the latter is the case, and you try the "rewrite in small steps" approach, your new code is likely to introduce new bugs to the existing V1 functionality. So you have to test on both kind of devices thoroughly, and may loose existing quality on V1 for the first releases. The new code will also be not really releasable at the beginning (not as a firmware update for existing V1 hardware in production), since it will miss some of the existing, working functionality at the start. On the other hand, reusing the existing V1 code mostly unmodified will you provide you with a production-ready version for V1 from day 1.

  • Thank you, I especially like the idea of limited time frame. – user124017 Mar 20 '14 at 19:23

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.