Good Code is a State of Mind
This week I wrote a new API class for our application framework. It’s not groundbreaking by any means. But it does provide us with a way to have a single point of access to multiple database classes. We can now expose any function we want, from any class we want, anywhere in our application, to API calls from the outside world. The rest are kept safely behind the wall with a set of custom API and secret keys. The cool thing about it, is that you can hand the new API class just a function name and its parameters, and it will figure out which class needs to be instantiated, create it automatically, run the command, and hand you back the results (good or bad).
Like I said, not groundbreaking. But in the end it gives us an easier-to-use API interface (both internally and externally) and allows us to eliminate the hundreds, if not thousands, of lines of code from our application that managed API calls for each of our database classes before.
The design for it came to me after I spent a couple days of just tinkering around with concepts used in the Amazon Web Services SDK. After some trial and error I suddenly had an “Ah HA!” moment and within a couple hours had written this new API client for us.
I lamented a bit afterwards, sort of kicking myself for not thinking of it sooner. The new method is far more elegant, requires much less code, and is way simpler to use. One of my co-workers reminded me that, at the time I came up with the old way we thought it was the right way too. Perhaps a new and even more elegantly simple way will reveal itself in the future.
We sit around talking a lot about new(er) technology, and had a conversation this week about PHP and Javascript frameworks. Sometimes we’re trying to think and plan when we can try out and implement a new technology platform. Other times we’re proudly describing the really cool things we’ve built from scratch for FXP|touch (and there are quite a few). I keep reminding myself that I have yet to have a customer tell me, “I’m not using your software because you didn’t use [insert your favorite framework here]” (and I’ve been at this a long, long time). Customers really just want your software to work as advertised (first), work in cool ways they didn’t imagine (second), and continue to meet their expectations over time (third).
If you’re doing those three things, your customers [mostly] will not care that much about what your application is written in or how.
BUT … as technology professionals, designers, programmers … we need to continue to innovate. We need to experiment with new ideas and new technologies because, at some point, we’re going to stumble onto something that saves us a bunch of time coding, or makes the application run faster, or communicate more efficiently, or allows us to do something we’ve never been able to do before. To accomplish these things though, is more about giving yourself the time to invent than it is the particular technology you’re looking at.
I was kicking myself for not thinking of the design sooner. The only thing that was stopping me was giving myself the time to sit and think and focus on the pile of code on the desktop in front of me. Time to tinker and build, to run things and break things, to try this and that. Pretty soon the new design just popped into view.
The thing I walked away with here, was that the design I came up with didn’t need any new killer framework or platform. It merely required allowing myself the time to apply some brainpower too it.
As it turned out, the best solution was just a state of mind.
