Rewrites Happen. Don't Limit Yourself
I talked about this before: I rewrote Tekpub 3 times to date. Rewrote completely as a matter of fact. It drove my partner
James Avery bonkers, but I was ... shall we say a bit driven.
Our first go was a mess. It was ASP.NET MVC and we threw it together quickly - spaghetti-coding our way to going live with our idea. It's true that if we took another few weeks to do the [All The Things] then we'd have a more maintainable application.
We'd also be down one partner as I had exactly 6 weeks until the money - all of it - ran out. This app needed to live, and I accepted the fact that I would be refining as time went by.
It wasn't complete crap - but I think most developers who code their first startup would tell you something along the lines of "yah - I really hope no one ever sees what I did. It was horrific." What I wrote for Tekpub v1 was along those lines.
You Will Be Wrong: Plan For It.
When's the last time your App Design Plan accounted for you being completely wrong? Wrong about your DB design? Wrong about your platform and language? When something goes that wrong it usually involves heads rolling and the business thrashing for a bit.
If you go into it knowing that your first rev is likely to be completely thrown away - well you might be depressed but at the same time you'd be prepared, and you'd also likely be correct.
Fast-forwarding to where we are now: I'm immensely happy (James is too) that we rewrote the app. It's not a terribly complicated application, but you'd be surprised at the things it needs to do. The end result is that both of us can make a change within 20-30 minutes and our application gives users what they want.
For me, as a business person, that last sentence is all I care about: our Users have the experience they want. I don't foist my technical limitations on them because I'm not willing to change my mind - or worse yet to admit I'm wrong.
Development Is an Act of Creation
A lot of Software Architects bristle at this assertion - that you can't plan as much as you think you can. I'll posit this: you're the only one who digs your design plan. End users don't care about you, your design plan, your Agile process, or your MVP status. They want their experience - give it to them.
My good friend
Miguel de Icaza encapsulated what I'm trying to say here during a conversation at MIX one year. The conversation was about some type of "Driven-Development" - *DD if you will, and Miguel had the best line I've ever heard:
I'm sure that's a lot of fun but writing code for me is an act of creation... it's an art form. I'm a Code Artist and because of that I don't put structure around it.
Bingo. At the time people laughed and no one challenged him. He'e MIGUEL - you just marvel that someone so capable is even
I over-think things. So do you. Maybe even Miguel does at times. In fact last night when
Scott Hanselman and I were recording Episode 12 of
This Developer's Life I kept tripping on what I was trying to say. I'd get caught up in a sentence, look up at the ceiling... curse and get pissed off. Scott said simply:
Stop thinking about it. Let it happen. You know what to say - just let it out.
And I did. In fact half-way through we stopped and realized that it didn't "feel right" - so we decided to record over. Both of us could have been upset and frustrated (it was rather late) - but we took it in stride.
Our attention to detail is important to us - if it doesn't feel right, doesn't come out right - we give ourselves permission to do it again. This podcast is for you - and we really want you to enjoy it.
Rewriting Is Not Failing
It's confirming that Code can be Art. An application is an artistic endeavor and if you allow yourself, as Scott said, to "Let it Happen" your users will feel your inspiration.
I'm not suggesting you stop writing tests or Cowboy Code your way to happiness. Perhaps let the plans and process wane for a bit and see what happens. Spike a bit more.
You have it in you - just let it out.