Why Programmers Should Plan

As programmers we all have had the instinctive urge to ditch the planning phase of a project and jump in with our metaphoric guns blazing. Personally, I know I've given in to that urge a time or two.

However, planning has some meaningful benefits. One of the biggest has nothing to do with the project; it has to do with future employment.You see, if you keep the coding separate from the design,you can often apply your design skills to projects which will ultimately be written in other languages. This yields a few different benefits:

  1. You are promotable from coder to analyst.
  2. You can make system-neutral arguments which can help justify keeping and expanding the MultiValue systems you support.
  3. It is easier for you to survive in a company which moves away from MultiValue, increasing your options.
  4. It lets you learn new languages and incorporate them into your tools, making you a more valuable employee or consultant.

Think of it the way you think about tuning a car. You can learn how to tune a 1979 Impala, or you can learn how to tune pre-fuel injection cars in general. Learning the Impala, you might pick up some tricks which are specific to that car, making you better with that model.However, learning tuning at the broader level means you can do a good job in more situations,even if you can't do the absolutely best job in the one specific case.

Nothing is stopping us from learning both.

Planning to Fail

One of the exciting aspects of planning is that it helps you fail faster. Given a choice between hitting a dead end six months into a project or six days into a project, I vote for the faster one.The sooner,and therefore cheaper, I find the roadblocks, the better my client or employer can make decisions that allow the project to restart or readjust. I've worked on projects where planning has allowed me to convince the boss to hire more staff or redeploy the folks we already had. I watched someone lose a job once because they didn't raise their hand soon enough. By the time management knew that things were at a standstill, the investment of time and money was so high that someone was getting fired.

So, I don't mind failing early. It is much easier to adjust the plan and try again than to adjust a million lines of code. Planning, unlike coding, is a journey you might be able to share with other, less technical people. I've had any number of visionaries, who despite being code-illiterate, understood so much more about the business than I did. Coding as I went would have cut me off from their participation. Sometimes a failure isn't considered a failure if it is discovered communally and resolved by the group.

Show Your Work

In math class, you could often get partial credit for a wrong answer if you showed your work. More importantly, the teacher could show you where you went wrong so that you had a chance to do better next time. I never do a project on the assumption that I will never have to do anything similar. Every project is prep for the next project. So, the better we set up the experience for learning, the less pain we feel on the next project.

When we plan, we show our work to others, including them in the process. We increase the number of voices— for good and bad—and we spread the understanding of why we do what we do. This brings me to the story of a chemist friend of mine. She called me one night in an attempt to make sense of her boss's recent hostility.When she started the job, they got along famously. He was her mentor. Recently, she had begun working more independently, and he had started shooting down all of her projects. She didn't think he could be jealous, she was still well below his level, but she was at a loss for a better reason.

So, I asked her if she had come to him frequently with questions in the beginning and she says, "Of course." Then I asked her if she thought that the questions gave him some insight into her thought process, and she said, "Absolutely." So then I asked if she was now presenting conclusions without explaining her thought process and she said,"That's it!"

The next day she presented a new project and included a section on her thought process, her dead-ends, and her eventual conclusions. He approved the project. Showing your work is very useful.

Leap of Faith

Let's assume that you believe that planning has a sufficient value. The next step is to understand how to maximize that value. When I have the option of setting the pace, which is certainly not all of the time, here's my preferred method:

  1. Meet
  2. Build a Straw Man
  3. Build a Plan
  4. Get Buy-in

Meetings, to quote one former coworker, are often a group of people sitting around a table, trying to contact the living. What we are looking for here is some healthy exchange. Generally, I try to get one of the people who need the project talking and then I ask a few wide-open questions. The more general the question, the better the chance of getting a useful answer. "What's the biggest issue we need to solve?" vs. "Do you want that as a report or an inquiry?"

Once they are talking, get the other people engaged. If the project serves Accounting and Sales, make sure you get both sides talking. Otherwise you end up with half a project specification. Hopefully, the key people will start interacting and refining the idea.

The Straw Man is a term used for a military practice dummy. It is something that can be cobbled together quickly, ripped to pieces, and remade as needed. My Straw Man is the meeting notes. Publish the notes in summary to all parties and tell them that you aren't positive you have it all right in your notes, i.e., ask them to rip it apart. Most people can't write a top flight IT project specification. Almost anyone can point at your notes and say, "Line three is wrong.We never sell single units."

Once the Straw Man has been savaged— perhaps in more than one goround— you can build your plan. The neat thing is, you have done very little work at this point.You sent one e-mail after sitting in one meeting. Instead of taking the entire project—win or lose —on to your shoulders, you have a group doing the bulk of the functional specification for you.You have people starting to feel connected to the project. You have some people besides you who see a success as their success. This will make them more helpful when we need to test or revise later. After all, it isn't your project, it's everyone's project.

When you build a house, you consult non-builders on things like the number of stories. Those answers imply technical answers about how solid the foundation has to be, even though you never asked about the foundation. In all technical fields, certain A information implies certain B information. So, while my customer didn't tell me to program in Delphi instead of PHP, I know the strengths of each language I use and I can make a best choice analysis from the facts I have been provided.

Likewise, in a MultiValue project, I should be able to select the right tools for the job at hand. That might mean introducing a 4GL, a reporting tool, or other existing technologies. It might mean leveraging the tools which the company already owns. It might mean redesigning database files. Moving from the business level specification to the technical specification requires you to have more than one skill, so that the choices are derived from the best course of action instead from the limits of the team.

Let's use a practical example and see where it takes us. Walt has a client with a billing system that was designed for a small medical practice. The client has a small medical practice, but they've elected to start a clinic and they don't want to abandon the system they have; they want to expand on it.

So, following the practices we just outlined, Walt meets with all the interested parties, sends out his straw men, and reaches a consensus.

Since the practice uses a 4GL already, he's going to do the project with those tools. Since the 4GL uses the Web as an interface, Walt uses his business plan to convince the client to hire a web designer to make the pages look right and flow smoothly. Now, he has to make the leap from business plan to technical plan, and layout the project.

Architect-Ive

Walt starts his technical plan by reviewing the existing database architecture. He wants to make the project work smoothly with the existing billing system, so he needs to understand the relationship between the fields and files. This will allow him to selectively add fields and possibly files to the layout without duplication or conflict.

Pseudo-Coder

Next, Walt needs to rough draft the programs and flow. Wisely, he throws out every hint or suggestion that uses a flow chart. What? Yes, Walt knows that flowcharts are useful in explaining technical matters to non-techs. He may actually design the charts — or some of the charts — after the project is complete. He won't use them in the design process because flowcharts have a fatal flaw. They take up more room than almost any other way of describing a process. As a result, you have to either pin them to a wall and walk back and forth, or page through them, or print them so small as to make them barely readable. None of these options make them easy to keep in your head.

A much better alternative, the one Walt chooses, is to pseudo-code. He writes a series of programs that look like figure 1.

SUBROUTINE Billing.Correction(Phase, Params, HTML, Status)
* by Walt Aminit
* on 04/01/08
* ***********
* This program is designed to allow
* for adjustments up until the bill
* is printed.
* ***********
* Initialize
* If Phase=new:
* --Paint Screen (Web Page)
* If Phase=check: 
* --Evaluate Params
* --Send back errors in Status
* --Send back errors in HTML
* --If no errors, send user to next page
RETURN ;* Logical End of Program
*
* Start of Subroutines
*
END ;* Physical End of Program

Fig. 1

This gives him a very compact way of looking at the program flow. Unlike a flowchart, it fits on one page. Unlike a flowchart, he can stick code between the lines, which turns these comments into internal documentation. Unlike a flowchart, if he strays from the design, the comments are right there to remind him that he is changing things, so he can decide to keep to the original plan, or have a clue that he needs to amend the downstream code to reflect that he has chosen to intentionally stray from the design.

As he moves forward, his code moves with him, as you can see in figure 2. He adds some additional pseudo-code as he goes, but the only real code he adds at this point is branching code (GOSUB, CASE, IF, etc.). He does this because getting the skeleton right is easier before the working code is installed.

SUBROUTINE Billing.Correction(Phase, Params, HTML, Status)
* by Walt Aminit
* on 04/01/08
* ***********
* This program is designed to allow
* for adjustments up until the bill
* is printed.
* ***********
* Initialize
GOSUB INIT
*
BEGIN CASE
   CASE Phase = "N"
      * If Phase=new:
      * --Paint Screen (Web Page)
   CASE Phase = "C"  
      * If Phase=check: 
      * --Evaluate Params
      * --Send back errors in Status
      * --Send back errors in HTML
      * --If no errors, send user to next page
   CASE 1
      * Error in Phase, only "N"ew and "C"heck
      * Are supported
END CASE
RETURN ;* Logical End of Program
*
* Start of Subroutines
*
INIT:
* TBD - Add Initialization Code
RETURN
*
END ;* Physical End of Program

Fig. 2

Oddly, many non-programmers can read a program that is just comments and branches. So, pseudo-code can be superior to the flowchart in this way as well.

The middle ground between the pseudo-code and the business spec is called the "use case." It is a method for making software more robust by setting up a series of "what if this happens" write ups:

  • What if the customer wants to split the bill between two credit cards?
  • What if the customer wants to pay in installments?
  • What if the check bounces?

When a business person thinks in use cases, reading CASE statements becomes almost natural to them.

Rad Catcher

Since the client is using a 4GL, Walt might have another starting point besides pseudo-code. He could consider RAD (Rapid Application Development). While RAD is possible without a 4GL or an object-oriented language, it is much easier with one of these tools. One of the biggest problems in completing software projects lies in designing interfaces which make sense to the people who will be using the project. The idea behind RAD is that designing the screens rapidly can save huge amounts of time and effort.

Where pseudo-code is primarily about the process, RAD is primarily about the visual elements. So, Walt can start by putting together a quick entry screen and treat it just like he treated his other straw men.

"Sally, have a look at this page for the billing entry. Let me know what options you need that I've left out."

This allows us to get the comments, complaints, and compliments before the code is finished. Personally, I'd be willing to jump through a lot of hoops to avoid having to do fundamental redesign on projects that are already having birthdays. RAD doesn't require a lot of hoops, but it does dramatically reduce the amount of late-phase redesign.

RAD extends the amount of time during which the business professionals can actively contribute to the design and implementation of the project. Most 4GLs allow you to create working screens (with little or no validation) in a few minutes. Walt elects to do both RAD and pseudo-code, so that he develops the engine at the same time as he builds up the screens. Since both techniques allow you to make mistakes and redesign quickly, he isn't trapped by any of the decisions he makes early on and can learn from his peers on the non-technical side.

  • When Walt is done building a usable version of the software, he has achieved several important goals:
  • Walt's client knows why he has made the choices he has.
  • The client has an emotional stake in the success of the project.
  • The project has a high chance of meeting the real needs.
  • The skills he has applied make him more valuable on future projects.
  • Walt now has friends and allies at the client. People trust that he can listen and deliver.
  • Because he has included them in the design cycle, the perceived time between the end of the spec and the release of working code is shorter.

If the next project uses a different 4GL, a different database, or serves a different business need, Walt is still a strong candidate because he can do the analytics even in a situation where he can't do the coding. It seems that project planning not only increases the chance of success but it also improves your reputation.

CHARLES BAROUCH

Charles Barouch is the CTO of HDWP, Inc. He is also a regular contributor to International Spectrum Magazine, a former Associate Editor for both Database Trends and for Gateways Magazine, a former distance learning Instructor for CALC. He is presently the Past President of the U2UG. Mr. Barouch has presented technology and business topics in front of hundreds of companies, in a wide range of product and service categories. He is available for on-site speaking and consulting engagements in and out of the United States.

View more articles

Featured:

Jul/Aug 2012

menu
menu