I recently read an interesting article about problem solving. Hopefully you have time to read the entire article, because it's great, but the summary is that figuring out the right thing to work on is a critical ingredient for success, and that it's pretty easy to spend too much time working on the wrong things.
The article tells the story of several teams chasing a prize for human powered flight. After 10 years of effort without any success, it occurs to one individual, Paul MacCready, that the real problem that needs to be solved is not human powered flight, but the ability to rapidly develop and test disposable prototypes.
Up until then, each plane had taken "upwards of a year" to be built, only to crash to the ground in the first few minutes of testing. Each trial would take an entire year of effort. But, with the new approach, "the rebuild, retest, relearn cycle went from months and years to hours and days." The prize was claimed within a few months after implementing the new approach, 18 years after the competition started.
I really like this story, because I find some small similarities with it and the development of SCADASuite and our application framework. We started out wanting to develop applications for SCADAPack RTUs, but we found that developing a single application was extremely time consuming, especially when we included time for testing and documentation. Changes were even worse. If it took so long to build a single application, how were we ever going to build a suite of applications?
The answer was to take a step back, and start working on the right problem, which was building our application framework. Using this framework, we can develop applications in weeks, instead of months. If an application isn't right, we can rework the whole thing in days. With the framework in place, we could finally start delivering the applications that we wanted.
Below is an interview with Elon Musk about SpaceX where he says something similar: it's really important to ask the right questions, and sometimes even smart engineers are guilty of spending too much time optimizing something that shouldn't be there in the first place. We could either have worked harder at building individual applications, or we could take a step back, and think about whether building applications one by one is the right approach.