I work for a small company and have been designing a GUI to interface our embedded system. The problem with this embedded system is that it is not a finished product (may never be) and is constantly under development and being tweaked and updated for different customers and applications in small volumes.

So to deal with this I made a program that can export all the data from a spreadsheet where most of the embedded system variables are sourced from and throw them into a small database for the GUI application to use. This database program I made also spits out a cross reference file for the embedded system which allows the GUI to look up all the variables.

This system works pretty well so far, and is even integrated with version control among the GUI, database, and embedded system. The big problem is that there is constant development on several projects that use this system and it gets terribly tedious to keep the system up to date and bring in new changes. This has gotten to the point to where I have had to code the GUI to dynamically (generically) generate all interfaces since I am never guaranteed to find the same data the same way. I have not been able to come up with a good way to uniquely identify the data I import from excel since all fields are able to be changed (due to engineering stubbornness, code re-factoring and/or excel issues) and I cannot assign a fixed reference within the sheet itself.

So, are there any good methods or ideas on how to handle the chaos?

  • "find the same data the same way" what do you mean with that? Which language are you using?
    – user827992
    Jul 6, 2012 at 19:03
  • C++ and SQLite, but the issue isn't the language, it's the source. I can't look up an item the same way between implementations if there is no way to have a constant identifier between all the different projects and versions of each. For example, there is a field that contains the cname of the object, if a programmer decides he wants to change that, I can't use that item as my consistent identifier between various projects and versions. I have tried to key the data on import to the database, but if a new item is inserted in excel, the id's will be different the next time I import the data.
    – radix07
    Jul 6, 2012 at 19:10
  • If you let the user change 1 field with an undefined option of its choice, you just have to deal with an infinite amount of options or you can do some casting to convert everything back to a limited amount of options, but this will break the deal with your choice at the first place, so even the casting does not make much sense in this case. I think that you can't really solve this if you leave this liberty to the user, also who needs an infinite amount of options? this just make noise and increases the chances of having duplicates with the same meaning. continue
    – user827992
    Jul 6, 2012 at 19:27
  • Only an human can deal with that code, a pc just can compute a limited amount of options.
    – user827992
    Jul 6, 2012 at 19:28

2 Answers 2


I think this is not a programming but a management issue, and what you currently do seems to be the best you can achieve. I also agree: this is far less than what you should have.

The problem here is that the component structure and interface definitions (the very heart of the system) looks like a playground. If this was a software product, it would like programmers constantly change "their" components "because they have to", and don't care about that the other programmers code don't compile or break. Sounds like a nightmare... The good news: the same scenario is already solved in software development with version control systems (committing, testing, branching, etc.).

I know nothing about your environment, but I think you (and more importantly, your managers) should consider this a problem (source of bugs, frustration, decreasing efficiency and reason for colleagues wanting to leave), and handle it adequately. Benjamin correctly detailed the technical part, I would add the management and architecture side. My quick, unverified idea is the following:

  • implement or use a simple type management toolkit describing the components, attributes, services - the result must be a plain text config, json or xml file! These files should be version controlled to follow the changes.
  • for any modification, the hw guys should create a new branch, where you should add your components. The point: you can simply diff the type descriptors and change your code accordingly.

If this component descriptor part gets its real, "master" role in the company with proper technical background, other tools may appear, like:

  • header source code generators on both the GUI and the HW service layer;
  • working property sheets runtime generated from the type defs, ...

These are not that great deal, I have done such things just because this makes development more efficient: having the "core functionality" available from the configs leaves more time to do the real job (and less repeated errors). I am sorry that I can only talk about this, my public stuff is only on "proof of concept" level, but the sources here might give you the taste.

These are serious programming efficiency and system stability boosters - but this can't be reached if the core data descriptors are handled in a spreadsheet and can be changed anytime, "just because" - and by my opinion, this is not a gui developer problem, but a management level issue.

  • Very helpful feedback. This is what happens when there are a bunch of hardware guys developing code and no true software people in a very small company. Much of this could be resolved with an intermediary database application I have made to import data and generate files which could be used as the source eventually. I am just a little unsure on the type management toolkit and component descriptors. Having troubles finding much useful information on that design methodology.
    – radix07
    Jul 11, 2012 at 14:58
  • @radix07 Welcome. But this is not that special at all: just think about configurable sw components, web service descriptors and app startup parameters: we "sw guys" are just as sloppy about the external interface of our components as your hw partners ;-) I am afraid, this is not a bottom-up solo project - but if you think about it for a while, collect the problems caused by it, and the requirements and concepts of a central type management, perhaps you can get some support to carry on. And anyway, it will make you feel better, and help organizing what you do... :-) Jul 11, 2012 at 18:54

So, what I understand is that you parse an Excel spreadsheet that is changed constantly by your colleagues. Here are some ideas on how to remedy that situation:

  1. Teach the other programmers to be careful with their changes. As soon as an API (in this case, the spreadsheet format) is public, it must stay that way or be deprecated in a controlled, system-wide way. It's uncomfortable, but necessary.

  2. Very effective together with the above would be automated testing. You said that everything is in version control. Set up a system that runs automated tests each time someone commits a change. If the tests fail, the commit should be rejected, if your VCS allows this. The goal is to always have a working, reliable state checked in.

  3. If the spreadsheet really needs to be changed all the time with no regard to compatibility, try and come up with a system so that the burden of adapting your interface is on the guy who changes the spreadsheet. Maybe some domain specific language, another GUI or some kind of annotations in the spreadsheet itself. Use the automated testing from above to verify consistency so your users are forced to keep the interface up-to-date.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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