Heal Your Church WebSite

Teaching, rebuking, correcting & training in righteous web design.

Make your Mistakes on Paper before you Code

Here is a little free advice from someone who’s been there and done that software thing for a little over 20 years. Put down the hammer and pick up the pencil, because it is always easier and cheaper to make mistakes on paper than it is in production.

A couple of weeks ago, I read an interesting post on SlashDot entitled “Attitudes in IT – Mediocrity Wins?” where a programmer is paraphrased to say:

“I’ve spent the past two working almost full time on a dynamic, database-driven web site for a client. Today I received an e-mail from the client pointing out a site by a competitor ‘Doing exactly what we are doing.’ On the contrary, is four static pages that employ javascript-launched email instead of forms for input … How do you deal with a client who compares your quality work with a shoddy rush job?”

My short answer to this poor programmer is, “you don’t.” Specifically, you should never find yourself in a situation where midway through development your pastor is wondering where the website is, and why it doesn’t look as good as the site for the Baptist church down the street.

Failure to Plan == a Plan for Failure

I’m not alone in this assessment, as you will see if you read some of the comments left on SlashDot in reply to the above question; for example:

“Yes, but was that in the specs? Or was that something you voluntarily done for your client? If the client’s requirement was “a simple Web site showcasing our products and allowing people to contact us”, then he’s right in pointing out that some things can be done cheaper and faster. You might have implemented scalable multi-processor algorithms for error-checking the text in the Web form, what does he care?” – #9261119

Had the programmer in question understood the obviously simple needs of his client then he wouldn’t have spent almost two months working full time on something that could have been solved with four static pages; as is reflected in yet another notable quotable:

“Could it be that your client is right? I mean, if your pages have a beautiful back end, but a front end that looks like processed yak’s droppings, isn’t there a good chance that a prospective customer will go for the more ‘professional’ website? You might have an amazing database engine, but if it is not visually appealing, there is still a major issue.” – #9261158

Even closer to my point:

“… a MAJOR part of our client relationship is TEACHING THE CLIENT what a good website is, etc. Since almost 100% of the sites we do are heavy cgi-bin coded sites (C) with database handling, image processing, etc… there are many factors in such sites that require us to teach the client why one approach is better than another approach. THIS SHOULD BE DONE UP FRONT – NOT AT THE END. You have committed to an approach, but it doesn’t strike me that you have educated your client as to the pros and cons of your approach.” – #9261265

In other words, had the programmer successfully walked their client through some sort of formalized requirements analysis and design specification, then it is more than likely the customer would have been educated enough to understand the differences – and know exactly what they wanted as an end product and when to expect each portion of it to be done.

The Dirty Little Secret

Websites are software, and as software, their implementation and ongoing maintenance tend to follow some form of a Systems|Software Development Life Cycle (SDLC) that includes some variant of:

  1. Analysis
  2. Design
  3. Development
  4. Testing
  5. Deployment
  6. Maintenance

In many shops, phases 3 and 4 are performed at a unit level, then integrated and tested at a module level, then integrated then tested at a system level and then deployed; while others employ a far more ‘Extreme Programming‘ approach to steps 1 and 2.

Regardless of one’s preferred modeling theology, it is my opinion that the plight of our put-out programmer is that the analysis didn’t include a survey of competitive sites. I will also go as far as to speculate that the design possibly didn’t offer the client unit-level milestones that addressed and enumerated the specific and real needs of the client in clearly defined and testable axiomatic semantics.

In case you’ve missed the point, even your church website should go through some form of a needs assessment and/or requirements analysis before you write a single line of code. Mistakes on paper are always less expensive than in code. Moreover, a well planned web site is far more flexible to change while being more resilient to feature-creep and/or situations where a client beats you over the head with your competitor’s work.

Required Reading

For more information on how an ounce of essential computer science will save you a pound of pain I’ve listed some sites that either discuss this topic in greater detail and/or offer examples of how to get it done:

“Therefore I do not run like a man running aimlessly; I do not fight like a man beating the air.” – 1 Corinthians 9:26

Don’t beat the air, plan diligently and avoid your ‘Death March‘ today.


  1. So right on Dean! Thanks!

  2. So right on Dean! Thanks!