This is not exactly a hack, but a good comparison of "good enough for now" vs. "future proof."<p>10 years ago I worked for a solar monitoring startup called Energy Recommerce. This is one of the most satisfying jobs I’ve had in my 20 year career. I did all of the embedded programming to implement our data logger: the provisioning UI, the drivers to collect data from devices, the database, and the mechanism to deliver data to our backend. We collected performance data from residential and commercial solar systems, and reported production data to state governments so the system owners could collect production rebates. We helped commercial solar companies manage their systems, including some big-name companies. The engineering team was literally me and one of the founders.<p>There were a lot of hacks and short cuts, but I will tell the story of one particular design decision that carried us for years, but was ultimately replaced.<p>We made the decision to define classes of devices (power meters, inverters, string monitors, weather stations) with a fixed set of datapoints, regardless of what each individual device could do. We then collected the data provided by the device and filled in the object. Sometimes a datapoint in our object was not available and we stored a NULL value. We scaled values to the units we defined in our objects (e.g., kw to w). More often the devices provided more data than would fit in our object, and some customers started asking for these datapoints. This meant we had to defined extended versions of some of our datapoints; meter_ext, inverter_ext, etc. This meant now we had two sets of objects, but the basic model still worked. We also sometimes had data collection bugs: collecting the wrong datapoint, or a scaling a value incorrectly. This meant the data was invalid and we had to update the software on the data logger to correct the issue. Still, our team was small and we moved fast.<p>Our biggest competitor at the time was a company called Fat Spaniel. We were always a bit baffled by the size of Fat Spaniel - our team was 5 people, including business development and software dev. Fat Spaniel had, in comparison, lots of funding and a much bigger team, but their customer base was not much larger. What were they doing?<p>Eventually an inverter company called Power One acquired both us and Fat Spaniel, and combined us into a single organization in San Jose. This turned out to be great. We combined into a single, really effective team, and I had a chances to peek under the hood of what Fat Spaniel had built.<p>They had made a fundamentally different design decision: they collected all the data provided by every device and delivered it to the backend. Once on the backend there was a complex xml-based system that defined what the data meant and put it into the same sorts of objects we had. If they found a bug in the way a datapoint was assigned, or the way it was scaled, they could fix the definition and then re-play all the data they had collected. Because they had the raw data from the device they could always go back and add a datapoint or fix other issues in the historical data.<p>This system was fundamentally more complex to develop, and required a bigger team, but it was grounded in good principals. It became the system we based our combined operation on. In fact, what we did was adapt the hardware and firmware that we had developed at Energy Recommerce to use the backend that Fat Spaniel had developed.<p>The system Fat Spaniel developed was technically better, and resulted in less technical debt. However, it was considerably more complex and took more money to develop. This meant their burn rate was much higher and they moved more slowly and we could compete head-on with them using a smaller team and less money.<p>[edited to fix cut&paste error]