As many of you have surmised, one of the tangential as-the-world-turns subplots of More than a living is following the development of a tool we’re building called Kumquat. As such, we’ve tried to be as open and honest about not only its development, but the mistakes we’ve made along the way.
A few months back, we got really excited. Super excited. Ridiculously excited. Really super ridiculously… Well, you get the picture.
We got excited because, functionally, the tool was just about there. All of the little bits and parts seemed to be working. I had just sketched a UI that would work for the first iteration of the product. All that remained was creating the CSS that would allow the application to look like the sketch.
Now, I’m generally one of those people who is lucky enough to know what I don’t know. And because of that, I try to leave work to the experts.
I didn’t try to build the tool with my coding knowledge, because I knew an expert would provide more value.
I went the same route with the CSS. Hire an expert.
And, at first, it seemed that everything was going along just swimmingly.
But, then, things started to get a bit more hinky. The consistency concerns were almost corrected. The usability issues were sort of addressed. The beauty of the interface was almost there.
But we never got there.
So after a great deal of hand wringing, I made a difficult decision. I pulled the plug on the CSS developer. I knew it was time to quit.
So begins the next chapter of the saga.
“We’re 80 percent of the way there,” I said to myself, blissfully ignoring the good old 80-20 rule and its equally demonic converse. “I’m sure I can put in a few extra hours to drag us over the finish line. I mean, I’m just painting walls and hanging curtains at this point.”
Well, yes. In a sense.
But I was painting walls and hanging curtains in a carefully constructed house of cards.
Tweaking a major element resulted in a cascading avalanche that wreaked havoc throughout the site. Starting at the very most cascaded element resulted in a multitude of other elements shifting around the UI.
It wasn’t pretty. And it didn’t validate.
Pretty soon, I had put in half the time the original effort had taken. Then 100% of the original effort. Then 150%. And all the while we seemed to be losing ground. Not gaining it.
So I talked to some people. People I trust. I asked them to tell me what I already knew. And they did.
So, then I made the hardest decision I’ve had to make, yet.
I told myself to quit.
Not only that, but I decided that we needed to go back to the beginning with the presentation layer, all together. Scrap all the spaghetti code that now existed in a bunch of style sheets. Start fresh.
And, I’m a quitter.
So that is where we are, today.
It was a difficult decision. Even more difficult than holding off on the launch. I don’t like to quit. It has never sat well with me. And it was all the harder to make that decision with something that has had so much of my emotion and sweat in it.
But it was the right one.
So I quit.
We’re tearing the house down to its studs. Fresh paint, window treatments, and all. We’re going back to the bare bones application. And we’re going to start fresh.
Where does that put us in terms of delivery? Hard to say.
But you, gentle reader, will be one of the first to know. After I know.
More than a living 
I’m reminded of the movie War Games where, at the end, the computer says: “An interesting game. The only way to win is not to play.”
I am the exact way when it comes to getting something done. I know I’m not the best at it, but I learn along the way and figure it will just be trading time to dollars.
In my case, I add to the problem because I’m thinking it will take even more time to find the right person for the job (who should develop my custom theme?).
So in the end, I don’t respect what my time is worth compared to the dollars I would have spent to simply change the person doing the work.
So after all of your effort, bravo for making the right decision. Yours is not an established product that can afford to take a hit. It needs to be good right out of the box.
So take the lessons learned and make the whole thing better. How many times have you said “if I could do it again, I’d…?”
Well, here’s the chance!
Good luck.
Scot,
Thanks for taking the time to add this commentary. (I see a great deal of myself in your comments.)
And, I really appreciate the positive reinforcement. This wasn’t an easy one for me. Not by a long shot.
Three words; “duke nukem forever”.
I understand your decision, but applications need to evolve naturally and trying to make it ‘perfect’ first try will only slow it down.
Just put the thing online, warts and all, and see where the users take it. Just make sure you appriciate the early adopters and make them feel apart of the process.
If the thing functions, and functions well, then people won’t care much about how it looks. And you can always tweak as you go.
“Ugly is the new black” remember?
Martijn,
Yes, indeed. And Chinese Democracy. Both referenced the last time I put the kibosh on the release.
And I have had the “MySpace” discussion with folks internally. Do we release something that doesn’t meet our aesthetic goal?
If the functionality is there, will the ugly be forgiven?
I can’t answer that. But I really appreciate your taking the time to provide that view. Even if it does make my decision all the more difficult. š
So, now we’ve got one vote for wait and one vote for go.
Anyone else have an opinion on it? We’re all ears.
Hey guys, I feel for you. This is one of the hardest parts of software development, imho, and lots of people (that I’ve talked to) blame it on offshoring (or in this case, simple outsourcing). The truth is, it’s really, really hard to get a project from idea to delivered. A couple of thoughts:
1. Read Seth Godin’s The Dip. He talks about how and when to quit. I don’t think, though, that you are quitting. Quitting is walking away from it all and doing something completely different. You are just regrouping.
2. My personal preference on this stuff came from my mentor at Simplot – it was all about doing “enough” and delivering the project so it could be used and useful – NOW. We did that with JibberJobber – we spent 2 months in development and then launched. We’ve been adding, enhancing, polishing since then, but what we had after two months was “enough.” In this last year we’ve made major progress in areas that we could not have made if we didn’t release last May. That is, we’ve established traction with our brand, with the press, with users, etc. So my vote is, clean up what needs to be cleaned up, release the first version, and you will definitely be making changes based on user input. It’s a lot cheaper to do it this way then spend another 6 – 12 months on “your design” and then release and then get real user input… and have to regroup then!
Good luck – and nice, transparent post.
Jason Alba
CEO – JibberJobber.com
because no one has enough job security…
Jason,
Thank you so much. I can’t tell you how valuable it is to have that sort of feedback, directly from the trenches, as it were.
I agree that part of the problem is my own “perfectionism.” For me, it’s really hard to let it go without a certain level of “making sure everything is just so.” I have really, really hard time subscribing to the Guy Kawasaki “Don’t worry, be crappy” mantra.
To be honest, I’m beginning to see this as a flaw of mine, rather than an asset. I feel like we’re getting ourselves into a situation of crying wolf, if we don’t get this thing out the door toot sweet.
Of course, no one is paying as much attention to this as we are. So, I also feel like I’m pushing this too fast, just to serve an audience that may be a construct of my imagination.
Welcome to more transparency on my psychosis. š
Seems like the prevailing thought is that we get the functionality out the door and save the presentation layer for a future release.
Maybe our challenge going forward should focus on “How Soon Can we Quit?”, such that we ensure we kick crappy out the door asap, and quit that version.
It’s good to hear from others that this isn’t a unique frustration – but it sure feels like it in the quiet of the night when we’re pulling the plug on things for the time being.
That said, “regrouping” is definitely the right interpretation on this account. I’m looking forward to getting this thing out the door, and shifting our discussions to needed refinements.
Thanks to all for your empathy and insights.
tl
I have silently been following your blog and the progress of Kumquat. Your post here really is inspiring to me to focus and refocus.
You did the right thing. When things start becoming a big mess and a headache. Take a step back, evaluate where your focus is and refocus, if needed. The reoccurring theme that I hear lately is that “You learn more from failure than success.”
I have been comtemplating a certain side project for the past couple of weeks. It is centered around a CSS community concept (no, it’s not another CSS gallery, thankfully) and your post made me think it through more. I had already focused on what I want to do with it, which is to help people learn CSS and the basics of good, clean markup while helping the advanced crowd to keep their skills polished. I truly want it to be a useful and helpful site. Your words are a reminder to me to keep it simple and try to stay focused on those core aspects. (I may need to write down my core features on paper and tack it up next to my laptop so I am constantly reminded to stay the course.)
Jason Alba brings up some very good points for not overdoing it. I am involved with innerTee.com and we’re finally back to a regrouping phase where we can redo some things better (amazingly enough, we were nominated for a SXSW Interactive Finalist Award). We haggled over a lot of details, some of which were important while others turned out to be time-wasters. It’s a learning experience, but it helps you to realize that you can over analyze it, which is what I tend to do most of the time (If only I could have hindsight AS foresight). It’s good to mind the details, but you can’t let the every minute detail delay or kill your project.
Jason is right. You have to eventually release something and polish it as you go. I think, from a user’s standpoint, it can be exciting to see a product maturing and being able to have a say in features, bug fixes, etc. We have done that a lot with innerTee and it has worked well for us and has also developed an extremely excited and pro-active group of users.
Anyway, I look forward to seeing what else you have to say and how things progress.
Kumquat may (har har), I wish you the best.
Eric,
Thanks for taking the time to add to this discussion. I really appreciate your insight and advice, from both objective and cathartic angles. š
Considering it over the past day or so, with the comments and the continued review of the situation, I still think we’re doing the right thing, pulling this back.
But, that said, I do hear the sense of urgency, as well. I’m not ignoring that.
So that makes the primary question “What is the presentation layer required for launch?” Which is a very different question from the one I was asking a few months ago. Now, I am thinking “From a usability standpoint, what do people have to have to use the tool?” rather than “What do I want this to look like?”
I’m glad our failures–and they are failures–are helping inform your thinking and planning for your next project. Knowing that almost makes me feel like failing, again.
Almost. š
Well, if you are content to fail for my sake… it might keep me from it. š
Failure is good for growth and learning, but it rarely pays the bills in a timely manner (it does pay off in the long run, though). I know it is frustrating to feel like you wasted money, time, resources, etc.
It sounds like you are right where we are with innerTee. The mixing tool needs an upgrade and we’re trying to decide what is most important and what is just us thinking a feature would be cool to have. Obviously, there is balance to be had and I think it is trying to figure out where that balance is that drives most of us crazy.
Again, I think you are doing the right thing. Bottom line, it’s your baby. Call it a Higher Power, instinct, gut or whatever, but ultimately, YOU need to decide what to do. Don’t let user urgency decide for you and then put out a half-baked product that you hate.
One big factor for me is feedback. When I feel frustrated about a project and the visual aspects, I ask my wife to look at it. Is she a designer? No, but she keeps me grounded to the goal/task at hand. Having outside people (that you trust) look at what you’re doing can provide an enormous boost and energy to stay on course (refocus, backtrack, redo it, etc.).
We do tend to isolate and emmerse ourselves into our work and project(s), but you have to come out of that hole every once and a while and ask the users/friends/clients if you’re still on track. That doesn’t mean you have to abide by everything you hear, either, but the feedback is a key motivator and stimulant for an altered direction (or different altogether), new ideas or just sticking to your plan. I think we rely on ourselves far too much for getting things designed or developed from start to finish. It’s like we think we’ve failed if we have to ask for feedback or help when, in actuality, it is a strength and provides a relief from a burden we can’t always bear ourselves.
Whenever I get discouraged about a personal project and constant delays I always have to remember: Being the first one to provide a product or service is never as important as being the one that does it the best. Being the best takes time, failure and patience. (I don’t remember where I heard that, but it has stuck with me for quite some time).
Sorry if I ramble too much (I guess I like to write). š
Eric,
If rambling were a problem, this blog would be relatively devoid of any posting. It’s all welcome here.
We have been overly conscious of getting outside help on the project. But I think we could a better job of getting more outside feedback.
The biggest challenge of this project–and the primary source of the frustration I’ve been voicing–has been my being relegated to the role of “overall management.”
I’m usually a “do-er” and this is one of the few projects I’ve tackled where I have relatively little to offer in the realm of heavy lifting. I can advise. I can pontificate. But there’s very little that I can do–especially in terms of meeting my own expectations.
I would love to dive in and rescue it by sweating it out, but that’s not going to happen.
This is why I was always a far better player than I was a coach.
It’s also why I’m subsumed by a feeling of helplessness.
I’m going to actively seek some more of that outside feedback to see if we can refill our reserves a bit. Maybe that will help get us to the first finish line, and ready for the next run.
Thanks for the advice. And for the back and forth. Very helpful.
Pingback: Sticking to your guns | More than a living
I’ll try not to keep blogging inside your commenting system, but here goes:
I hear you, though, on wanting to dive in and just fix it. Sometimes, we have to see it as a learning opportunity to step back and let otehrs come in and advise, create, fix, etc.
Your coach/player illustration is a good one. I’ve never played baseball competitively, but I’m helping coach my son’s t-ball team. I was surprised as to how much I actually DID have to offer while helping coach. Most of the dads had played competively, but learned things a certain way. Not all of these 4 year olds will be able to learn those exact same methods so I was surprised when my methods worked for some of the kids despite being very different than the other dads’ methods.
I think not playing ball competitively while growing up helped me to develop a different perspective on it. I tend to develop tailored methods instead of broad sweeping ones that may work for some, but not others. The same is true with my work.
I tend to work better with tackling a problem one task at a time or it can be easy to get overwhelmed. This also allows me to have more breathing room. The only problem I see with this though, is that you don’t always have as much time as you’d like to work with someone or a task one-on-one/one-by-one.
this is one thing i wanna do but i can’t…just love to read what’s on those techy minds of other people…