The Perils of Application Frameworks and Functionality-Biased Programmers

So I completed work on a mobile app not too long ago—it’s always an enjoyable and gratifying experience to deliver projects to our clients.  This time, however, there was a catch. For this particular app we had initially decided to try out a framework that uses HTML5, CSS3 and Javascript to replicate the look and feel of a native mobile app.  The framework appeared to be well-constructed, well-documented and even more importantly, well-suited to the requirements of the app.  Although I loved all of the functionality built into the framework from a data delivery and manipulation perspective, it turned out that the appearance of suitability ultimately revealed itself as a nasty illusion when I tried to learn how to incorporate a custom visual design into the look and feel of the app.  This became such a mountainous obstacle that we eventually decided to abandon this once-promising framework for a solution that offered more flexibility in the area of aesthetic appeal and usability.  It was big disappointment to come to the realization that we had invested so much time in what turned out to be the wrong framework for the job.
Now that I’ve had a little time to think over this recent project, I have begun consider a few things about the two major mistakes that I made along the way. First, I chose the wrong framework. Second, I probably spent more time than I should have trying to pound a square peg into the round hole.  The first mistake is one that all developers try to avoid in the first place—if (or should I say when?) one does make such a mistake, it’s always good to have a plan B to fall back on, which we did.  In this case plan B was better than plan A.  As it is, I learned that there were some gaps in how I previously went about evaluating an application framework. In particular, I overlooked how challenging it might be to customize the look and feel of the framework that was my initial favorite.
Learning from the second mistake seems to be a case of discretion being the better part of valor.  I fully believe that there is a way to accomplish what I wanted with that first framework but that I simply don’t currently have skill and familiarity with that framework to do it.  Eventually I would have gotten there but that’s a battle for another day.  Learning to avoid the second mistake for me is a matter of balancing persistence in the face of a challenge with enough awareness of my own strengths and limitations to recognize when too much persistence becomes just plain stubbornness.  In that regard, I might have sooner asked myself if I was trying to overcome the challenge out of a sense of personal pride or if it was really in the best interest of the customer.  Had I done so, I think I would have been quicker to move to the solution that we ultimately decided on.
Web development is ever a process of learning–whether it’s new technologies, new programming languages, new ways of programming in existing languages, or just figuring out how best to apply them all to provide our clients with websites and mobile apps that set their brands apart from crowd.