When software gets little

14 Jul

Posted by Andy Brudtkuhl under Business, Development

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

What do you do when software gets little?

Anyone who has ever developed an application most likely knows what I am talking about, unless they are an uber-developer who creates the perfect application every time.

Software gets little at the end of a project - when all that’s left are the little things. To me, this is the worst part of the project. My mind works on the grand scheme of things, which is why I like being a software architect. In the end of a development project you are working on spec changes, bug fixing, visual tweaks, font changes, etc, etc, etc. These are all the little things.

What’s tough about this stage is two-fold: 1) there is less reward for accomplishing a little feat, and 2) it’s much harder to get and stay organized in the very dynamic environment when your application does get little.

This is true in any project if you are an event planner, a project manager, a construction worker, etc. You start with a goal and a plan. And every reached milestone along the way is a success. But every milestone still contains little things that you decide can wait until the end. Then once the end is reached, you have a bucket full of disorganized little things.

Sometimes you want to disregard the little things as what they are — little. You say, ‘That’s not a fundamental aspect of the project, let’s just forget about it’. But the value of the little things does not correlate to the impact they have in the project or the time it will take for you to finish. The little things create value that is unbeknownst to you until you implement them. They are the glue that holds your project together — what makes your project a success.

What do you do when your projects get little? How do you stay organized? Better yet, how do you abstain from having a bucket of little things at the end of a project?

technorati tags:management, lifehack, project managment, software development

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Get GetANewBrowser delivered to your inbox

No related posts, you should check out...

February 13, 2006 -- technorati adds relevance
August 8, 2007 -- Social Bookmarking in Plain English
March 1, 2007 -- A Million Dollar Marketing Budget
July 9, 2006 -- Delicious Library
September 6, 2007 -- A Google Ad War

4 Responses

TheBizofKnowledge

July 14th, 2006 at 3:11 pm
1

The best way to prevent having a bucket of little things at the end of a project is to pay attention to details along the way. I know that there will still be things that inevitably slip through the cracks, but by keeping an eye on details, you’ll hopefully be left with precious little to fix after the major milestones are reached.
karmatosed

July 14th, 2006 at 5:13 pm
2

I have found that if you do the project in phases and set those as rigid for completion of all tasks - this is a good way to stop the bucket effect. I like to work and manage projects this way whenever possible and it usually is if you just adjust your thinking.
Joel

July 15th, 2006 at 2:01 am
3

it’s all about the 80-20 theory…
Andy Brudtkuhl

July 15th, 2006 at 9:01 am
4

Sometimes functional milestones must be met before the 80% trivial items. In that case I use prioritized lists of trivial items. For instance validating a form is going to be more important than changing a stylesheet.

Sometimes having a bucket of little things is good in that it allows you to trim the fat off your application by realizing that many of the trivial items are no longer necessary to implement for your application / project to be a success.