Starting in the Middle and Writing

I read a good piece over on To-Done about starting projects in the middle.  I see that  today’s Signal vs. Noise noticed it as well.  I’m usually hesitant to make “me too” posts, but I think that this is a good enough insight into project work to be worth parroting.

Britt makes a good point about not necessarily needing to start a new project by addressing the first element of the requirements.  I do this all the time with writing.  It’s rare that I’ll write anything from start to finish.  In general, I write small one- or two-sentence snippets that serve to illustrate some part of the point I want an article to make.  If I’m lucky, I’ll get a whole paragraph out.  Then I just drag and drop these snippets and paragraphs into the order in which they make the most sense.  Voila!  Finished article.

Truthfully, I figured everyone worked like this.  Let me ask – how many of you actually start your writing project by writing Page 1, or start developing an application by coding Requirement 1.0?

If it works, it works, and that is one of the highest values to which any project can aspire, but starting with the beginning and ending with the end just seems like an un-naturally orderly way of doing things.  I always try to run tight projects, but just a dash of chaos seems to do a good job of greasing the wheels.

Coming Up For Air

I know it’s been too long since my last article when people start eMailing me to ask why I haven’t posted a new one yet.

Things are busy, busy, busy here at Cogeian Systems.  I’ve currently got a team of three working crazily on various projects, and am about to add a fourth.  My current project-load reads like a countdown:

  • 5 web apps
  • 4 desktop apps
  • 3 articles
  • 2 products (stealth mode!)

And it’s all leading up to…

  • 1 nervous breakdown!

Just kidding.  😉

As busy as I am, I’m actually enjoying things quite a bit.  This is the biggest year yet for my little company, and the coming year looks to be even bigger!  This has been a very exciting year.  It all leaves little time for blogging, but I need to make time.  2 of the 3 articles I mentioned above were started for this blog, but abandoned in favor of addressing the backlog of billable projects.  I busted hump to build my business to this point, and I’d hate to lose traction now.

That said,  I have to acknowledge that blogging is – in part – what helped me build my business.  My blog directly helped me to close 2 of the projects I have right now, and influenced the closing of 2 others.  So, I’ll be devoting time to finishing up those 2 articles in the near future.

Thanks for being patient!

The Very Best Thing About Working From Home

I’ve commented on the challenges of working from home before.  Now, let me tell you the best thing about working from home.

My little boy is home sick from school today.  I was here to comfort him when he woke up in distress.  I was here to sit with him and eat lunch.  I’m here to hear his CD player playing John Lennon’s Imagine as he lies in bed, resting.  When we take him to the doctor in an hour, I’ll be right there with him.  When he goes to bed early, I’ll be right here to rub his head and sing him to sleep.  If he’s well enough for school tomorrow, I’ll be dropping him off in person, and I’ll be there with my wife to pick him up after class.

As much of a stickler as I am about not being interrupted when I’m working, being right here, owning my own little company, allows me to have the option to decide when I get interrupted, and for what.

Paul Dix Gets It

Today I caught a post on Paul Dix’s blog that made reference to my item on 11 Clients You Need to Fire Right Now.  It’s always nice when a smart guy like Paul mentions something I wrote (thanks, Paul!), but even better was his account of firing himself from a project before it even happened!  It sounds like Paul is working close to capacity, and turned down what looked to be a perfectly fine project for fear of not being able to devote the appropriate time to it.  In Paul’s own words:

Like many programmers I often get into the position of overextending myself.  Not this time. This time I decided not to over-promise. This time I decided to be realistic. This time I realized that I have enough on my plate. This time I realized that taking on another project may cause me to shortchange all of them.

Make no mistake – that is professional-level thinking.  And that is the kind of thinking that will gain our profession the respect that it often lacks from clients and employers.  I’m pleased to hear that not only is a fellow developer wise enough to avoid a no-win situation with regard to being over capacity, he is also doing well enough to be able to turn down work.  I may preach about best practices when it comes to managing some projects and cutting others loose, but I haven’t forgotten that turning down or terminating a project is much more difficult when you’re down to your last $50 and have no groceries in the kitchen.

Good show, Paul!

Has anyone else recently avoided or terminated a no-win project?  Let’s hear your stories!

edit:  Sanjeev has started a discussion of this topic in the forum, since I forgot to post it myself.