It's better to finish something that's not quite right than to continue to tweak and tweak the unfinished piece. It's much easier to go back and fix something that's "done" than to finagle with nuances of something you're still working on.

The emotional value of finishing is underrated
Too often, we underestimate the emotional and motivational value of work that is simply...done. Perhaps, it's not the end-all final product. Perhaps there are tectonic changes to be made. But the mental lift-up of knowing that an execution is complete is largely underrated.

Programmers and designers don't usually talk about emotion because it feels like a weak excuse, but it's apparent in everyone I've ever worked with - most notably myself. The good feelings of getting things done have huge implications on how well and how efficiently you continue to do your work. The bad feelings of tweaks during development and building software still not graduated from "idea-mode" have an equally negative impact.

The perceived problems of changing functionality is overrated
At the same time, the perceived headaches of trying to tweak functionality after the fact, even deeply rooted functionality, is entirely overrated. The reality is, very few add-ons, removals, or logic shifts are undoable. Good programmers prepare themselves for this anyways. The basis of design patterns and best practices is largely to accomodate for the very real fact that what your code is doing today will likely get tweaked (endlessly) tomorrow.

Iterative development is the antidote to this problem in some ways. It gives developers a taste of being done each time an iteration is released and clients the privilege of tweaking at frequent pitstops along the road to the perfect end-product. Yet, iterative development still works too largely in favor of the latter. It quickly starts feeling like the finish line is a long way off.

It works both ways
Finishing a flawed product isn't just for the sake of the developer either. It's so much easier to see what you really want to change, what's clearly important and what isn't as important as you thought when you see something in its current "final" state. There are no more what-ifs, there are only yesses and nos. Something does or doesn't work like you really want it to. These are things that a developer can take back to the shop and change.

I'll take a completely solidified, 90% correct concept over a 90% solidified "perfect" idea. Going back and correcting completed software is far more palatable than the two-steps-forward-one-step-back dance of code that's trying desperately to finish itself and be perfect at the same time.

The Cowboys spent $1.2 billion on this strategy
I wouldn't apply this methodology to all industries - like real architecture for instance. Yet, sometimes it happens anyways.

The new Dallas Cowboys stadium (at a cost of $1.2 billion) has a major flaw. At just 90 feet off the ground, punters are finding they can easily hit the $40 million, 11,520 square-foot scoreboard. If Cowboys Stadium were code, we could easily adjust the scoreboard height. In real life, it's a multi-million dollar job.


Their solution? The NFL has instituted a new do-over rule on punts that deflect off the scoreboard. I'm not sure if I'm completely happy with a rule that sounds like 6th grade gym class, but, it's a simple change that costs $0.

If league officials had cared about this detail before the stadium was finished, the Cowboys would likely be taking snaps at the Wal-Mart parking lot across the street this Sunday.

Labels: ideology, programming

We've long been told that we need to be thinking outside the box to avoid getting caught in the traps and problems that typically appear when we plod along through things doing them the same old way and making the same mistakes that we always collectively make. I, your humble narrator, agree that this is indeed Sage And Great Advice.

BUT!

I feel that sometimes we work so hard making sure that we are thinking outside of one box we end up putting ourselves in another box with its own confusing, harsh, and this time more surprising set of problems. After all, we were thinking outside of the box -- why are we in another one?

In case you haven't guessed where this is going, this entry is another in my line (does a pair make a line? Note to self: find out.) of posts supporting the idea that imposing a set of constraints on yourself -- in this case working within the box -- can often free your mind to worry about other and more important things. Ken Arnold agrees with me, and Joel Spolsky agrees with him! *Even though they both thought so before I wrote any of this!*

I got to thinking about all this because I was recently writing a little game for my new Android phone (here is a little applet version! Based on simple-tetris-clone) and realized that I enjoyed all of the constraints (framed as Best Practices) that the folks at Google recommended we work within and follow. While I obviously didn't create a masterpiece of coding and design (at best, it's a mediocre clone), I still really enjoyed my coding experience and the creativity I had to use to tackle some of the issues within the set of constraints of the system. I continue to think that by embracing the limitations of these boxes we find ourselves within, we can come up with clever and creative solutions to problems that arise within this system.

In this scenario, I perhaps didn't have or want an opportunity to "think outside the box" and drift from the constraints of the system since part of my goal was to learn about the new platform and its best practices. However, had I decided to avoid the recommendations of the best practices and come up with my own scheme for something, I'm sure I would have run into some roadblocks that I avoided by focusing my energies on solving problems from inside the box.

Labels: ideology, opinion, ramble

With today's economic downturn affecting pretty much everyone everywhere, it's created an atmosphere of fear, uncertainty, and a general sense of dread -- much like those final, silent, slow motion moments before you realize that your car has been stolen... but it's not the end of the world! Today's stagnant economy offers opportunities that you may never have considered, just like losing your car (or any property) can lead to any number of positive outcomes (getting a new car, saving the money the insurance company gives you, riding your bicycle more, being outside, etc.).

Here at We Are Mammoth, we're looking for ways to turn today's economic zeitgeist (yes, I just wrote "economic zeitgeist") into something positive. One of the main things that is changing here is how we answer the question "Should we build this, or buy it?" by deciding to buy products from vendors rather than spend our energies on building an ancillary tool.

By choosing to buy solutions to problems, we've freed up a lot of our time to focus on the actual meat of the product that needs the solution and thus provide our clients with more of what they came to us for in the first place: creative, interesting, unique, and highly usable applications. Secondly, I am a proponent of partnering with companies and people in such a way that we build relationships with each other that can benefit us both going forward. We have a great rapport with our hosting provider, Rackspace, for example that has opened up opportunities for both of us (I'd like to think so, at least) that would never have existed had we decided to do our own hosting.

We have also begun to embrace this ideology by releasing our own set of internal tools, namely X2O, to contribute back to the community in a way that we think can benefit a lot of people. By providing our infrastructure and exposing our methodology to people and organizations that we hope will partner with us, we're giving everyone an opportunity to adopt the things that have helped us to streamline our operations and focus on the heart of the solutions that our community is hired to provide for clients.

So, cheer up people! It's not all bad, out there -- with each problem that we are forced to confront, we are given a matching opportunity to find a new solution that may help us to change our thinking in a way that works as a catalyst for something positive.

Labels: ideology, x2o