[TID-BITS] : FROM FRANKENSTEINED TO FANTASTIC / BASTARDIZED TO BREAKTHROUGH
Web development straddles a fine line between creativity and functionality. This is called user experience and it’s very important in what I do. Presenting the user with something new and novel in a way that’s familiar and that their intuition helps them immediately understand and recognize is one of my favorite and dreaded challenges. My creative mind gets to go wild and my rational brain gets to slash it back. The visual, if nothing else, is entertaining.
So when I take on a new project, the first thing I do is familiarize myself with the 5C’s and start architecting the story that will reveal the problem so that I can craft the solution. Often the core requirements of the project or problem to be solved are overshadowed by visions of $1M in ecommerce sales and fancy spinning gizmets, so this is as much of an exploration and discovery for them as it is for me.
Fast forward through the process and we come to the point at which the plan is finalized, yet flexible, and ready for implementation. For a website, this is the point at which the development happens and the project starts to grow legs.
I included the word “flexible” above because never have I ended up with an exact replica of what I had initially conceited in my head. The process always encounters a snag needing to be worked through or reveals an alternate, better more efficient way of checking a component off a list. But while flexibility is more of a good than an evil, it does have the tendency to lead to “scope creep” from clients. Changing requirements happen almost inevitably on a project, and I don’t believe in building something that’s outdated or wrong before launch. But the path of significantly changing requirements can drastically alter the final product – for better or for worse.
At this point a couple things can happen.
“Frankensteining” begins with one request, which turns into two, which turns into [n]. In hindsight the “disasters” have been the projects on which I have not either had the time or the luxury of building in flexibility, or projects where I’m simply a “code monkey” playing request whack-a-mole. Small changes can lead to a “wall” where what was originally architected no longer works with the changes, whereby in hindsight I would have architected a very different project. Here I have to get “creative” which sometimes means cheating and rewriting core code (which in the technology world is akin to killing small furry animals).
On the other side of the scale though are those changed requirements that lead to brick walls – which turn into brilliant and even better solutions to the original problem. I can figure out the formula for this situation and how to apply it PROACTIVELY at the start of a project, well then I might just make the cover of FORBES Magazine. Or the New York Times. Or Rolling Stone.