How do you get past the Analysis to Paralysis when working on a new project?

Question

I've been struggling with how to get my project going. I've got an old software package that is in need of desparate rewrite. I haven't compiled the source code since 2004. It still sells, it's stable but does require the “Run this program in compatibility mode for:” on a lot of the newer windows systems. It's also one of those hard coded 640 X 480 screen resolution programs. Yuck!

I can't seem to get started with this rewrite. I'm constantly fiddling around with different things. I'll play around with different fluid layouts for a while. Then I start looking at how the main menu should work and look. I quickly find out that there's this thing called "Cool Bars" and I'll spend hours playing with that.

Then I start thinking about stuff like "Oh I need to make sure that the screen sizes are preserved so when the application gets relaunched it remebers how the screens were positioned." Which leads to what happens if they have two monitors? Which leads to what happens if they have a quad screen? Yikes it's got to stop.

I have always been a slow starter. I think about stuff long and hard up front. This has always plagued me. Once I get my mind made up though bam... I'm off and running.

I'm looking for advice from some other one-person software companies that can help someone like me get off to a quicker start?

Success

Thanks to everyone for your motivation. I finally have a plan in place. I wish I could split the vote between @haylem and @ThorbjørnRavnAndersen.

I went to download.com and filtered the downloads by my software category. I sorted by "Editors Pick" and downloaded a couple of the highest rated programs. On the second hit I found the final piece of inspiration I needed.

I love yellow sticky notes.

Answer 1

Short Version

By adopting Zed Shaw's Programming, Motherf*cker! methodology?

---

Longer (Serious) Version

While Shaw - despite being a bit overly enthusiatic and (way) over the edge - definitely has a point there, there's a bit more to it than that...

You quite simply need to learn to embrace something similar to a personal productivity ritual or methodology, like Geting Things Done, the Pomodoro Technique, or Personal Kanban.

You don't have to to adopt these books and tools in particular, but the concepts they advocate are entirely valid.

Keep it Simple

Here's the big secret. I use magic tools:

• TODO Lists,
• Time-boxing,
• Zero-Distraction or Distraction-Free Software.

Just Do It

The process to use my magic tools goes like this:

1. Suppress Distraction
   1. Close the office door,
   2. unhook the phone,
   3. close the browser tabs and communication software,
   4. put on your headphones (with or without music).
2. Plan for the Short-Term
   1. Take out a pad,
   2. write tasks down for the day,
   3. and set a timer.
3. Get Cranking
   1. Open your favorite editor
   2. and start Programming, Motherf*cker!

Sounds dumb and simple, huh?... That's because it is. Every time I'm hit by a blank-page syndrome attach, that's how I snap out of it.

You just need to get yourelf do these actual steps.

Do not over-think things, do not overengineer, do not stall.

Make it a Routine

Make this a routine, a habit. And keep it going.

"Old habits never die", they say.

---

Personal Anecdotes

It all starts with main()

When I was in engineering school and we'd have trouble getting started on the next assignment in a never-ending queue of stuff piling down on our ends with weeks of 70 to +100 hours of coding, we'd always just tell ourselves the following:

It all starts with main()

So you just type it in:

int main(int ac, char **av)
{
  /* conquer the world, here, now! */
  return (0);
}

And you're on your way. Stop arguing with your classmate / co-worker / pair-programmer / partner, and just start the stream of code. It's a bit like playing an instrument, where you risk suddenly having a memory lapse if you had the stupid idea of thinking "what's the next note?". Keep it natural and flowy, don't overthink it, just stay focused and let intuition and muscle memory do the rest. Not exactly the same thing, but close enough.

Home-Offices and Remote Work can be Hard

This sort of block can happen to anyone, but it happens more often when you work in isolation. Which is the case for people working remotely, from home. Which has been my case, for the past 9 months now.

And believe me, sometimes you do get into the state you just described: you just can't get yourself to do anything. Which is infuriating and frustrating all at once.

When that happens, get up, go have a glass of water, stretch a bit, take a 5 minute walk, play with your kid, come back, and use the technique describe above. It just works.

I know, I use it all the time.

---

There's even a lot more to it than this long version. We could write books - well, people did - on personal productivity and remote work. The key is start from these core-principles, and then adapt to your taste. Find your rythm, develop your routine and good habits.

Answer 2

Time Boxing

Don't give yourself "as much time as you need" for analysis. Just give yourself a limited amount of time. For example, "by next Friday I will have made a final decision on which UI paradigms I will support." Or, "within 3 weeks I will have implemented a working prototype of the Widgetizer screen".

It is better to have imperfect, working software than perfect, theoretical software. So don't focus on analyzing until the design is perfect. Time boxing will force you to focus on the critical decisions, and the less critical decisions might not be made with perfection, but that is okay. You will find that most of those decisions don't end up having any impact on the final result.

Answer 3

You need a deadline. Once you have a deadline, don't spend more than 1/3 of your time planning. After that you'd better be "doing".

Answer 4

excellent process answers so far, but let me address the question more specifically

if it sells, and the users aren't clamoring for new features (CoolBars, or whatever), then there is no reason to rewrite it

the only issue is the compatibility warning - this is where to start; this is the initial goal (as other have pointed out, it's the only obvious flaw in the system, other than screen resolution)

so instead of getting overwhelmed with all the what-if and should-I stuff, focus instead on the very next thing to do to make progress

i suspect that would be: recompile the system in a more modern development environment, to see if the compatibility warning goes away

if it does, yay! ship it!

then go talk to your users, and see what they would like to be improved. They may or may not care about the hard-coded screen resolution, so don't guess: ask

good luck!

Answer 5

I would suggest that you focus on shipping a new version where the only change is the new GUI. Everything else goes in the next-next version. Do this mercilessly - otherwise you will have too much work to do.

Whenever you look at anything, use the criteria "will it help me ship?". If not, leave it for later.