Get with the program
January 10, 2003
** Listen to this column on your computer, iPod or other audio player **
Programming has never been an easy high-tech career
path. Whether you are working in a corporate cube farm or on your own,
the technical issues of programming languages, data architecture and accessibility
issues are trouble enough, but the people issues can be even more challenging.
If you are planning on striking off into the programming field, you would
do well to consider the following issues.
When do I get paid?
One of the greatest challenges for a freelance programmer
is closing the deal. Too many clients want to endlessly “specify”
you to death. Some companies will not blink at asking for 4 or more meetings
to discuss the type of system they want, all without paying a dime. While
you may be tempted to keep the relationship going in hopes of a sale,
after the second meeting with the client, you should be working under
some form of contract.
Specifying the function and structure of a program or computer
system is as important (if not more so) than writing the actual code.
You should be paid for your experience and your efforts just as if you
were writing the program itself. In fact, as you move through the specification
process you are probably already making decisions about overall data structures,
user interface and database management.
Beyond the issues of contracts and payments, there are a
host of other pitfalls in the specification process. Too many clients
will come to you with the “Swiss Army Knife” project that
is supposed to not only automatically close the quarterly books, but also
monitor the status of the company’s coffee pots. It is to the benefit
of both your client, and yourself, to find no more than two major issues
to address in each programming project. If the client requires a larger
system with more functions, break it up into several sub-project with
their own specifications and contracts. It may sound like more trouble
to negotiate items separately, but it really helps to clarify goals, deliverables
and change orders in the future.
Change Orders
If you want to insure a calm programming life, you must
address the issues of project changes that happen as the project develops.
Change orders are inevitable. Often a client will spot a problem in the
specification only when the program begins to come together. Secondly,
once the client begins to see what the program can do, they will come
up with many ideas about what it should do. In these cases, you need to
have a policy about change orders.
I highly recommend that any change orders be treated as mini-projects or, if they are large enough changes, new projects in their own right. By negotiating the terms, scope and price of these projects now, you will have much fewer problems when it comes to the last project payment. I have seen negotiations over final payments go on for weeks as each side blames each change on the other. Confront this beast up front.
The beginning of the end
Of course, one of the most difficult parts of any programming project
is knowing when it is complete. Clients will push for one more change
and you will be chomping at the bit to move onto something new. If you
did your work well in the specification process, though, you will be ahead
of the game. As the project moves forward you should begin developing
functionality “punch lists” based on the specification documents.
This allows you to slowly “check off” each item as it is completed.
These punch lists then give both you and the client a clear indicator
of how the project is progressing and what remains to be done. They also
establish the concept that the project is complete when all the items
on the punch list are addressed. This won’t make you immune from
the various “end-of-project” issues, but it can go a long
way towards reducing their severity.
I am sure many of you thought programming was all about dealing with C++, SQL, PHP and more. I hope this column has opened your eyes to some of the project-related, and people-related issues, that will effect your high-tech career.
<%=INSERTTEXT%>