Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Paul Kimmel

Dr. Dobb's Bloggers

Timing is Everything

September 29, 2010

I went to the Heartland Developers in Omaha a few weeks ago. It was a great user event for developers. When I got back I put some Lentils in a pan to soak to make some hearty soup. I got busy and forgot about the lentils. A few days later I opened the pan with the soaking legumes and they had started sprouting roots. The Lentils went from soup starter to plants, from possible nutrition to living growing things.

This reminded me of the value of timing. Timing is everything. Soaked for a night and you have soup. Soaked for a week and you have living plants.

Software development projects depend on timing too. Spend too much time on the wrong thing or at the right time and instead of software you have a lot of everything else. A philosophy of software development that I follow is very simple: plan at the macro level as briefly as possible, figure out which elements you can buy or reuse, and then build the core system outward. The last part is one of the most important parts of software development. Identify the core parts of the system, the most valuable parts, and put all of your energies into those elements first.

If the core features can be identified and built first then you arguably have a usable system very early. A usable system is going to demonstrate value to the customer, later trade-offs can be made for schedule purposes, and project is less likely to end up as a death march.

Many projects I have seen get bogged on too many non-essential details of project scheduling, building data access layers, arguing about coding standards, GUI s or GUI standards, or excessive design and modeling. Often core systems, especially those that leverage existing code or components from external sources, can be assembled in kind of a skunk works mode. Then, elements of a macro schedule can be converted to detailed micro schedules for sub-systems, again building from the high value, high risk, priority items out. Things that are often not high priority or GUIs unless you are building a new kind of GUI, data access layers, documentation, tutorials, schedules, and standardization rules.

A reason what I refer to as lower priority items are built first is that often teams are assembled and re-assembled early on and not everyone is sure of what they should be doing. The way you combat this problem is to build the core sub-systems early with as few people as possible to seed inertia and demonstrate feasibility. Then, after you have buy-in, a core working solution you can bring on secondary players, like testers, documentation people and trainers, and GUI fit and finishers.

On many projects, even pretty large projects one or two people that work well together can get the core system roughed out before a lot of people are needed. This is true of enterprise systems too. For example, too many players too early and the project quickly derails into planning and scheduling, how do we get all these people moving at once. The hard truth is you can't unless it is a team that is highly cohesive, that has worked together, and everyone already knows there roles. Few such teams seem to exist, except maybe at places like Google and Microsoft where many of the same people are working on an existing vNext project.

In 21+ years of completing projects highly formalized planning, modeling and design, and inception with large teams seem to cause most of the problems.Build software with a few people first, identifying the riskiest, most critical elements of the solution, and add the overhead of task scheduling, planning, and formality slowly.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.