The High-Tech Career Handbook
|A weekly ComputorEdge Column by Douglas E. Welch|
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.
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.
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.