Who Are the People?

The people are your application’s stakeholders: whoever hired you, direct users, recipients of reports, the CFO who’s expecting cost savings, the CEO who’s expecting better efficiency, IT (information technology) people running systems you connect with, and anyone else who has a stake in the success of the project. It’s a mistake to take too narrow a view of users, probably encouraged by today’s emphasis on “usability” or “user friendliness.” Those are important, but many of the constituents you need to satisfy will never use the application directly, and may not even ever see it running.

For example, when I started working on a student information system for the Richardson (Texas) School District, I first met with the IT director, who sketched the project for me. The next day I met with his immediate staff of three people who had been struggling with an outside vendor since the start of the school year, when they first started using a new system. Months later, at a meeting that included the assistant superintendent of elementary schools, it turned out that what they wanted from me was a simpler system just for elementary report cards, which, of course, I said I could build for them. We called it Rgrade (R for Richardson). As I got into the design for this new application, I met with more IT staffers, some teachers, two people who ran the servers in another building across town, another assistant superintendent in charge of assessment (a very big deal in Texas), and a few other people whose names and titles I never quite got.

Who in that list had to be satisfied to make my project a success, in priority order? You need to prioritize, because, of course, you can’t satisfy everybody, at least not completely. Who had to be satisfied first, second, third, and so on?

Well, the first rule is that you most need to satisfy whoever hired you and pays you. (In Latin class years ago I learned that Roman soldiers were always paid directly by their general, never by the politician-controlled government, so the general could be sure they would be loyal to him.)

But, what would satisfy the IT director? He didn’t give a hoot about any of the features of the system, how easy it was to use, how much it cost to run (within reason), or anything else technical about it. I don’t know if he even cared whether the kids got graded. What I gathered from that meeting with the elementary school assistant superintendent was that the teachers were upset with the existing vendor’s system, and she wanted peace. The IT director wanted peace with her, since he’s the one who had put in the current system they disliked so much.

So, the next constituency to satisfy would be the teachers who would be using the system. My list ended there; there was no third or fourth priority. The server people didn’t matter, as long as I didn’t bug them too much. The IT staff members were irrelevant—they would be happy if they never heard of elementary report cards again, ever. As long as the report cards got generated, the assessment guy was happy.

The point of the story isn’t to present a formula for how to prioritize satisfaction or explain how school districts in Texas work (probably impossible anyway). The point is that, for any project, you have to come up with a complete list of all the people and understand what each of them wants, how their wants connect (IT director is happy if assistant superintendent is happy, which she is if teachers are happy), and how to maximize satisfaction.

Another example: I was vice president of engineering for a company that made a system for optimizing supermarket checker schedules, called SuperSked, which was sold to large grocery chains, such as Safeway and Kroger. This was a mostly off-the-shelf product, not a custom job like Rgrade. All of our customer interaction was with the operations department at the headquarters of the chain. The system was used by someone on the store manager’s staff, but we never met any direct users. Grocery profit margins are notoriously slim, so the labor savings provided by SuperSked were significant. That’s all operations cared about. Of course, the system had to be usable, but ease of use made no difference. If it saved money, the stores were going to use it, even if it meant entering data with the tip of their noses. Who did we have to satisfy? The operations departments.

Each case will be different, so you have to dig deep. Don’t guess.

How to Satisfy?

Knowing who to satisfy isn’t enough, though. You need to know how to satisfy them. Computer people call that “how” the requirements. It’s simple: if the requirements are right, and you meet them, the people you need to satisfy will be satisfied, and the system will be a success. If the requirements are wrong, you’ll satisfy the wrong people or no people, and either way you’ve failed.

I’ll talk much more about requirements in Chapter 2, so I’ll just discuss them at a high level here. For Rgrade, they were easy to articulate: the teachers wanted to have a single, easy-to-understand form that they could put the grades into, choose teacher’s comments from a list (the district didn’t allow free-form comments), and have report cards pop out in English and Spanish. The report card format was already defined, as were the Spanish translations of the comments. The output requirements were obvious: same report cards as they had last year and every year before that. As long as it did the job, what mattered most to the teachers is how quickly they could get the grades in. They usually did this work late in their workday, or even at home, and every minute spent on it was a minute taken from something else they’d prefer doing. Maybe lesson planning or helping students, or maybe watching football and drinking beer. But never Rgrade.

How about the input form, though? What should it look like? Well, I made it look just like the report card. It looked so much like that report card that the teachers needed almost no training at all. They thought they were typing onto the card, just as they might have when they used paper reports. All user interfaces implement models, and in this case the perfect model was easy to discover.

I did do two other things that I knew would be necessary to keep the teachers happy, even though they never mentioned them. First, I arranged for the system to be hosted by the people who ran the district’s servers, so it would be available 24 hours a day. Second, I asked for a lot of processing power, to make sure the system wouldn’t get overloaded. There were three high-end servers, one for the database and two for the application, with a nifty load-balancer at the front that sent web requests to whichever application server was least heavily loaded. That turned out to be overkill, but nobody in the IT department cared. Their definition of happiness is an empty backlog of trouble reports.

It sounds like a slam-dunk success situation, right? It does? Satisfying a few hundred put-upon Texas teachers who deal with the little monsters all day? More of a three-pointer than a slam-dunk! It only seemed simple because I covered the two essential steps: identify the people who had to be satisfied, and then figure out how to satisfy them.

Indeed, there were people who voiced their ideas for the system I was building, but I knew many of those ideas, especially from the IT department, wouldn’t appeal to the teachers. I was an outside consultant, so I listened to these people. But then I ignored them. I only worked to satisfy the IT director who hired me and the teachers. Nobody else mattered. If you try to please the wrong people, which is easily done if they’re the people you see every day, you lose.

(If you’re using an Agile methodology, with a customer on your team who tells you what user stories get implemented, you’ll fail if that person doesn’t accurately represent the customer who has to be satisfied. Too often the actual team member is someone from IT or a product manager, because the real person you want is unavailable.)

For SuperSked, what would it take to please the IT departments at the grocery companies? Yes, SuperSked, but only indirectly. Our real product was documented cost savings, and we had a PhD, one of the company founders, who worked full time on modeling the workforce and the savings from optimizing its costs. We could prove savings year after year, so the customers were happy.

So, just as you have to identify your real customers, you have to identify your real product. Then your job is to build and deliver that product, and that’s what the rest of this book is about.

Hiring the Best

When I first became a manager, I was incompetent at hiring. I didn’t really know how to do it, so I just wanted to get it over with as quickly as possible. That resulted in settling for people who were merely OK, but not the best. I cringe when I think of some of the programmers I hired for my company, XVT Software, in the late 1980s and early 1990s. But a few years later I read a book with the same title as this section, Hiring the Best, by Martin Yate, and I got a whole lot better at it.

Before you even get to the hiring part, you need to make sure the best people want to work on your team. If your company is in trouble, your technology and product are old, your salaries aren’t competitive, your location is lousy, or the project sounds dreary, you’re not going to get good people to work for you. (Maybe you shouldn’t even be there yourself.)

(If you’re not the hiring manager but a prospective hire, this matters to you, too. Look at the quality of the people already on staff.)

The company’s troubles and its location are hard to fix, at least right away, so you may have to live with them. What you can change is the technology, the salaries, and how you run the project.

If, for some reason, your organization isn’t using the latest technology—an obsolete programming language or operating system, or bad hardware—it’s time to upgrade. You can’t recruit the best people to work in old ways. If the system runs on Windows XP, move it to Windows 8. Code new web pages with HTML5, CSS3, JavaScript, Ajax, and jQuery. You might find that some senior managers balk at new technology, or are listening too much to customers who want to use Explorer 6 and old computers that can’t run the newest operating systems, so you may have to fight. The best people flat out won’t work on technology that they consider to be behind the times. If you end up with mediocre people whose own technical skills are out of date, you’re sunk.

When I was interviewing for a job in 2008 and noticed on the company’s web page that its product required Windows 95, a Pentium 3, and at least 500MB of RAM, I hoped it was just a failure to update the web page. Either way, it was a real turnoff.

Salaries, too, might need to be adjusted. If the cap for a programmer is $100K, you can’t hire the best. Far better to have five programmers worth $150K and being paid that much than ten making $100K. You’ll have a better team, and it’s cheaper, too. Some companies have a rigid pay structure that doesn’t allow a programmer to make more than, say, a senior accountant or marketer. Do what you can to get this changed. Maybe you’ll fail, but you have to try. If you can’t pay for the best, maybe you shouldn’t be there, either. You’re the best, too, right?

John Moores, founder of BMC Software, came up with a compensation plan he called “product author.” The main developer of the product got a royalty on sales. John told me about the “two comma club,” membership in which required an annual compensation number with two commas in it. He lent a Ferrari to one of his two-comma programmers to drive until his own came in. As you might guess, BMC Software was hugely successful and, for a while, had the highest revenue per employee of any company of its size in the country. Maybe your company won’t adopt a compensation plan like BMC’s. On the other hand, maybe you’ve already gone that far yourself: you’re a consultant, or, like me, sell your own software on your web site and in Apple’s App Store. (I’m only at one comma so far.)

Once you know the work is attractive and the salary range is right, you can begin the hiring process. An in-depth discussion of how to do that is beyond the scope of this book, and it’s covered very well in Martin Yate’s book anyway. One thing I would add to his techniques is to look at the candidate’s portfolio, which in this case means a nontrivial program that he can bring in to show you. You might be told that all of the candidate’s prior work is proprietary and can’t be disclosed. Maybe so, but I’d be leery of any programmer worthy of being called “the best” who’s never done any programming at home on his or her own, even if it’s just a web page with some JavaScript.

One way to look at the candidate’s portfolio is at a group meeting, but you can also do it one-on-one. You want to hear the candidate explain the program, or at least a few sections of it, with particular attention to why things were done the way they were, and what alternatives might have been considered. If you know programmers, you’ll be able to tell pretty readily whether the candidate is really on top of his or her game, or is a plodder, able to get a program put together but not with innate artistry. That’s what you’re looking for.

I also ask questions like this one: to initialize the application, you need to read in a list of color names and RGB values from a parameter file, about a hundred in all, and sort them for later display. Should you use a bubble sort, insertion sort, or quick sort?

Two types of answers are wrong: an indication that the candidate doesn’t know anything about sort algorithms, or a firm statement that quick sort is the fastest. The best answer is this: I’d use whatever function was in the programming language’s library, or, if there’s nothing, bubble sort, since it’s the one I’m most likely to get right on my first try. Efficiency during initialization with such a small list is irrelevant. To paraphrase the old Charlie the Tuna ads, you don’t want the programmer who can sort the quickest, you want the one who’s quickest to sort.

Or, this question: We have a report generation feature that does a database query and writes a multipage PDF with the results, but customers are complaining that it takes too long to run. How would you fix it?

Here you want to hear an answer that includes these pieces: some determination of how long is too long, reproducing the problem so that there’s something to experiment on, instrumenting the system so the bottleneck can be identified, running experiments to see if any speedup is possible even theoretically, and then estimating the cost to fix the problem so a decision about whether to proceed can be made. Potential fixes, such as improving the query, adding indexes, or providing a queuing facility so the user doesn’t have to wait around for the results, are also good to hear. Mostly you want to learn how the candidate thinks.

What you don’t want to hear is a flat statement that the database needs indexes, that MySQL is the wrong choice, or anything else that indicates that the candidate has jumped to a conclusion. Nor do you want to hear, of course, that the candidate has no idea how to proceed.

My point is this: spend less time on educational accomplishments, previous job titles, and past projects and more on how the candidate approaches the work. This requires really in-depth interviews, not casual chats over lunch.

Scheduling the Unknowable

There are two main difficulties with scheduling.

• You don’t know the requirements, and they’re subject to change anyway.
• Even if you did know a requirement, it’s hard to predict how long it will take to develop.

And two lesser difficulties.

• Programmer productivity varies widely (10:1, in my experience).
• Much of programmers’ time is spent on nonproject tasks, such as customer and sales support, HR (human resources) meetings, and training, vacations, illness, and exploring new technology.

But you can’t let these problems stop you from scheduling—it’s too important. You still have to do it.

True, you don’t know the requirements and they’re going to change during development. But there’s a difference between not knowing the details, which might not affect the schedule much, and not knowing anything at all about what’s to be done.

Here’s an example: Let’s say you know you’ll need about 10–15 reports that all take the form of a database query, formatting the results into a table on a web page, and downloading the data as a CSV file. You can figure a week to build the overall template, and a day for each report, for a total of four weeks. That’s probably high, but safe. If you know the programmer doing the work is a crackerjack, cut it to a quarter-day per report, for a total of two weeks. So, one way or another, it’s two to four weeks. Not a week, and not two months. All without knowing anything about what exactly needs to be in those reports, which you’ll work out later with the customer when the work is about to begin.

Another example: You’re doing a project for a library, and one important feature recommends books based on other books that the borrower has read and liked. (Something like what Netflix does for films.) What should you schedule? A week? Two months? Three years? You have no idea. That scheduling uncertainty, though, has exposed this as a major technical risk, and probably a major development job. So, you immediately get one or two of your cleverest people to research what’s available, build a prototype, and demonstrate it to the customer. That might take a month all by itself, but anything this risky has to be done right away. If you need to add three months to the schedule to get this developed, far better to tell that to the customer at the start of the project than a week before the big Libraries International Trade Show, leaving your customer with a fancy booth and nothing to show in it.

So, you always schedule based on the requirements you do have, but you qualify that schedule as being based on loosely defined requirements. As requirements get more specific, you refine the schedule.

The second problem, not knowing how long development takes, is easier to deal with. Pick one or two programmers with the most experience related to the project at hand and have them estimate how long it would take for them to do each item in the requirements. For the nonprogramming tasks, pick someone who has those skills. Estimates can be in half-days, assuming a half-day is four hours. Make sure every task is included: documentation, training development, testing, localization, and everything else that’s needed for a complete product.

Tasks should be tagged as being one of three types, depending on how accurately they can be estimated.

• Type 1 tasks are similar to something that’s been done before, so their implementation time can be fairly accurately predicted.
• Type 2 tasks are new, but it’s well understood how to do them.
• Type 3 tasks are those for which the requirements are vague or the implementation approach is unknown, and estimates for them are wild guesses.

Next, apply a productivity factor to the estimates, because it’s likely that the top people you picked for the estimating are above average for your team. A factor of 2X to 4X might make sense.

Then figure out how many actual working hours there are in a day. If there are technical support and other nonproject duties, it might only be four. If it’s a new project, figure six. Seven or more is probably too optimistic. Assume only 40-hour weeks.

All the Type 2 tasks get an additional factor of 1.5X because the estimates were rough, and all the Type 3 tasks get a factor of 3X. You don’t really know that the factor is 3X, of course, but that’s OK for a start.

Total it all up and you’ve got the number of days it will take. Figure that there are about 46 working weeks a year (52 minus vacations, holidays, and illness), and you’ve got the delivery date, assuming the work is assigned so that everyone is busy all the time and nobody is waiting for anyone else. (A database centric design helps a lot here, as I’ll explain later in this chapter.)

Don’t like my arithmetic? Fine, use your own. The point is that you should use a method of some sort to come up with real numbers. The benefits of this exercise are enormous. Lots of questions will get raised, many of which will have to remain unanswered until later. Far better knowing what you don’t know than stumbling along with your head in the sand.

Any Type 3 (wild guess) tasks in the schedule make it very inaccurate, so the best thing is to split the project into two: a prototype phase, in which Type 3 tasks are reduced to Type 2 (but not actually implemented other than as a prototype), and then an implementation phase. Announce that the implementation schedule will be created only after the prototype phase. That way you’re not in a position of quoting a delivery date based on wild guesses and then having to revise it later.

The purpose of the prototype phase isn’t only to aid the scheduling. Getting the high-risk design problems out of the way at the start of the project also makes sense for development. You don’t know what resources will be required to explore this unknown territory, and you don’t know what impact their design will have on the rest of the system. Such large disturbances should come as early as possible.

(In the movie The Godfather, after Tom Hagen hears the producer Jack Woltz refuse to cast Johnny Fontaine, he gets up to leave, saying, “Mr. Corleone is a man who insists on hearing bad news at once.” As a manager, I insisted on that, too. Don’t worry, I never had a racehorse decapitated.)

When you get to the implementation phase, you have only tasks of Types 1 and 2. Type 2 tasks were less accurately scheduled, so move them to the front. Then as the project proceeds and the schedule is revised it will get more and more accurate, because the work in front of you is much more well-known than the work already completed was at the time it was scheduled. In addition, as you get further into the project you have more history about how productive the team is, so the time estimates are more realistic.

To summarize: You start with an inaccurate schedule, but one based on a detailed structure that reflects all the tasks needed to complete the project. After a prototype phase, you announce the schedule. You revise it as the project progresses, and it gets more and more accurate with each revision.

If you do it this way, the team will look pretty good, especially if they’ve been open about the kinds of uncertainty that were behind the initial few schedules. Even if the final date has to slip—and, with all my fudge factors, it may not—it’s OK to slip it by a week or two when you’re still six months out. It’s when a delivery date is blown with no notice that the team looks incompetent. This happens when the team tries—and fails—to make up for slippage by working longer hours, reducing testing, and cutting corners on coding. Schedule the right way and that will never be necessary.

If you find yourself working in an organization that expects schedules to be unshakable commitments and blames developers if they’re not, make sure you keep track of all the changes to requirements that will occur throughout the project. Then you can connect each schedule change to the requirement change that caused it. If those are the politics where you work, you have to play the game.

A Scheduling Example

The Conference on World Affairs (CWA) gathers about 100 speakers from around the world to participate in panel discussions on every topic imaginable in politics, arts, business, science, human affairs, and much more. It’s been held each spring for the last 65 years on the campus of the University of Colorado, in Boulder. Until I built a PHP/MySQL system for CWA this year, the organization kept track of everything related to the conference with Excel spreadsheets, text files, and a FileMaker database that ran only on the assistant coordinator’s computer.

Figure 1-1 shows a greatly simplified schedule, built with Microsoft Excel, for part of the CWA system. The Type 1 items (101 through 106) are forms, one per database entity.

The reports (107 through 110) are Type 2, because they all required generating a PDF from PHP, which, for the purposes of this example, I’ll pretend was something I hadn’t done before. The Type 3 items are for two components that I wasn’t sure about at all: a way to automatically assign visiting panelists to houses, and a way to determine whether each panelist has his or her speaking times well distributed. (I really didn’t do either of those, but let’s pretend I did.)

The columns are based on the scheduling methodology from the previous section. The Half Days column reflects how fast I think I can complete each task, assuming I know what I’m doing. The Avg. Prod. column applies a 2X factor to it, assuming I’m twice as fast as the average programmer. The Risk Adj. column applies the 1.5X factor for Type 2 items, and 3X for Type 3 (because I don’t know what I’m doing).

Notice how much the Type 3 times have expanded, all the way to 36 half-days to complete the housing assignment item. Perhaps that’s too little time. Or maybe it’s three times too long. It’s a Type 3, so we really don’t know.

What this model tells us is that we can’t really come up with a schedule until the Type 3 items are prototyped to the point where they become Type 2, or even Type 1. So, in planning the work, those two items would be the ones to be attacked first. Until there’s a working prototype that satisfies the customer, the project is in its prototyping phase, and there’s really no official schedule. When there’s a detailed design for those items, or, better, a working prototype that can actually be tried out, the implementation phase can begin, along with the first working schedule.

Poor Requirements

It’s OK, even preferable, to evolve the requirements as development proceeds, but they have to converge on something that leads to success. If the quest for requirements loops endlessly without ever crossing the finish line, or fails to target what the market wants to buy, the requirements process is faulty, and no amount of whining about the customer who doesn’t know what he or she really wants is going to save the day. The project has failed.

There’s lots more about requirements in the next chapter.

Weak Team

Nobody ever wants to say that the people on the development team just aren’t good enough. The closest they’ll come is to say the people were inadequately trained, which might be true. But, let’s face it, the people sometimes are simply not talented or experienced enough, or both. As I said earlier, with the best people you’re probably going to succeed no matter what, because the best people do what it takes to succeed. With the wrong people, it’s hard to see how you can ever achieve success.

Failure to Prototype High-Risk Features

You can’t just plunge ahead pretending that those high-risk, Type 3 features are normal ones. There’s a real danger that the project will get bogged down too close to the delivery date while the team is desperately trying to get the system working the way it was promised. As I said, the high-risk tasks have to be attacked first, not postponed so that the team can show early, but misleading, progress by picking the low-hanging fruit. (I’m reminded of a year-and-a-half delay in opening the new, completely finished, airport in Denver back in 1993 while the software running the automatic baggage handling system was being debugged. That part should have been worked on much earlier.)

Bad Design

Design is the process of taking the requirements and coming up with a blueprint for implementing them, somewhat like the role of architecture in constructing a building. If the design is bad, the project will fail even if the requirements are right and the implementation of that design is perfect.

In my view, many systems aren’t designed at all. The programmers take what requirements they have, perhaps only a week’s worth if they’re using an Agile methodology, and start coding. Few, if any, projects even have anyone with the title of application designer. True, there are user-interface designers, but the user interface is only a small part of design, just as door handles, elevator buttons, and HVAC controls are only a small part of architecture.

Poor Development Processes

Even with a good set of requirements, a project can get into big trouble if the development processes are poor. Among the sins are

• Waiting until late in development to integrate the components.
• Inadequate unit testing, resulting in failed integration and a lot of wasted time.
• Poor allocation of modules to people, without clear and minimal interfaces.
• An awkward and/or frequently changing database schema.
• Sloppy programming habits, not corrected during code walkthroughs.
• System tests with gaps in coverage.
• Not engaging the customer with frequent demos and alpha releases.

Changed Priorities

This was the killer of projects at Bell Labs when I was there in the 1970s. A project would get started, get staffed at a level only AT&T (Bell Labs’ owner) could afford, and then get killed a few years later because technology had improved (I already mentioned the AMDF project), the personnel were needed on a more important project, or the economics changed. Maybe another company would have thought more carefully before starting a project with such a questionable future, but in those days AT&T was a regulated monopoly and didn’t have to watch its expenses.

Today’s equivalent of changed priorities is probably VC drying up.

Sabotage

Sabotage is a deliberate attempt by a manager to kill the project, usually surreptitiously. A common situation is when someone who never supported the project replaces a manager. This and other forms of corporate in-fighting are outside the scope of this book; I list this situation here only to acknowledge that it’s pretty common.

Exploiting Database Centricity

That SuperSked application I mentioned a few paragraphs back was the first database-centric project I’d managed with more than two or three people on it, and development went amazingly smoothly, even though the application itself was fairly complex. There were almost no integration difficulties. Bugs found through testing were quickly identified and fixed.

We did a lot of things right: a terrific team of developers, well-understood requirements (it was a replacement for an existing system), and a tight, but reasonable schedule. But there was one more aspect of the project organization that really made the difference: all of the components talked only to the database. They got their data entirely from the user (via forms) or from the database, and they deposited their results back in the database. Components never talked directly to each other.

Testing was based on database snapshots captured from customers of the existing system and then converted to the new database, using the same conversion programs that would later be part of the deployed system. A component could be exercised in isolation, since everything it needed was in the database. (A few components required some data entry.) Then the results in the database could be easily checked. If anything was amiss, it had to be the component itself, since it couldn’t be an interface problem.

Good news: PHP/MySQL applications, the focus of this book, provide exactly the same advantage. To exploit that advantage, however, you have to design each component—each form, report, and business-logic module—to interface only to the database.

There were a lot of conversations between the component developers and the database designer, especially at the start of the project, as the schema was complicated, with many subtleties. But even those conversations pretty much stopped once the model was well understood.

Here’s an example of how components interfaced only to the database, instead of directly: the first step in scheduling the checkers is to forecast demand, based on the time of year, day of week, presence of holidays, predicted weather, and a few other factors. Second, labor availability had to be established, depending on work schedules, union rules, training (not everyone could handle the express register), and so on. The results of these two preliminary steps were then fed into a very advanced optimization algorithm that computed for a while, maybe 10 or 15 minutes, and then coughed up a schedule, which then got arranged into various reports, including one for posting on the employee bulletin board.

The obvious thing to do is to work out a way, using XML, for example, for the forecasting and the availability modules to connect to the optimizer. We didn’t do that. We had them insert data into the database, and we designed the optimizer to query the database for its inputs. One huge benefit to this was that the programmer working on the optimizer could just keep running it on the same inputs, without dealing with the predecessor modules at all. And, once the programmers working on them verified that the data was in the database correctly, they were done. No need to actually run the optimizer.

To the programmers who had worked on the legacy system, where the data existed internally in huge Fortran-style arrays, the idea of writing all those numbers into the database seemed very strange. But, once the functions to do it were coded, the job was done, and they never dealt with interfacing issues again.

Assigning Components to People

Many PHP/MySQL projects are very small, probably because large, corporate developments tend to use fancier technologies such as Java EE or .NET. I don’t have the numbers, but I’d guess that half of all PHP/MySQL projects are done by one or two people and a quarter are done by four or fewer. So, the work is usually divided up only a few ways.

For any PHP/MySQL project, and for most others, too, the categories of development jobs are

1. Database design and implementation,
2. CRUD (create, retrieve, update, delete) web pages,
3. Business logic (e.g., scheduling supermarket checkers, routing deliveries, computing invoices),
4. Reports and other outputs,
5. Conversion,
6. System testing,
7. Documentation, and
8. Training.

If there are two of you, one should do the database, conversion, and reports, because that’s nearly a stand-alone application. Once the database is loaded with converted data, there should be enough to test the reports. The other person can do the CRUD and business logic. System testing, documentation, and training can be split up any way you see fit.

With three people, if the business logic is complex, as it certainly was for SuperSked, that’s a full-time job, and other jobs can be split as they were for two people.

With more than three, it still makes sense to combine the database and conversion, because conversion exposes so much about what the database needs to be able to model. Also, once you design and implement the database, it’s no longer a full-time job. The other components can be split according to their complexity and the skills of the team members.

Remember, no matter how you assign the components, they only interface to the database, never to one another.

Have a Written Contract

At various times three of my friends have asked me to help them resolve disputes with their consulting clients. One had to do with a complex formula for payments on preparation of training lessons, one was about patent ownership, and one was about rights to the software. All three had this in common: there was no written contract. I don’t mean that there was no document drawn up by lawyers; I mean nothing written down at all.

I’m not sure why that was. Maybe they thought that a written contract required lawyers and they didn’t want the expense. Maybe they rushed into the project. Maybe one party wanted the flexibility to wiggle out of the deal later. Anyway, you shouldn’t fall into that trap. Get it in writing.

What needs to be in the contract? Well, they say that journalists are supposed to write the who, what, where, when, why, and how (except for weddings, where they skip the why). That’s a good list for a written contract, too. Who is going to do the work and for whom, what the work is, where the system will be developed and installed, when it will be delivered, and how it will be done. Skip the why if you want. But, include what sometimes follows a wedding: the divorce. State how the contract can be terminated and what happens when it is. Also include who owns what, which I’ll discuss in the next section. And, of course, how much and how often you’ll be paid.

Really, if any of my friends had that list covered, even as a set of non-lawyerly bullet points, they would have avoided their difficulties.

You might find yourself in a situation where you think suggesting that you and your client have a written contract will be offputting. In that case, don’t use the word “contract.” Just send an e-mail saying something like the following: “I thought I’d recap our working agreement, to avoid overtaxing our memories later.” Then go ahead and list the key points and ask the client to confirm his or her agreement via a return e-mail. The e-mail will probably clarify any disagreements down the line, and if it doesn’t, any mediator/arbitrator will work from it—med/arb is a very flexible process. So might a court, but you’re very unlikely to ever get that far.

Know Who Owns What

You deliver the system to your client, but does he or she own it? Do you? Can you use any of the code for another client later? What if it includes code you’ve written before the project started? Did you lose ownership of that? What about patents? Copyrights? Trademarks?

All of this is called intellectual property (IP). On every project I’ve ever worked, the client owned everything that I developed during time billed to that client. I never cared about owning any of it, because of the nature of the work. But, if you’re being hired to invent something truly novel, such as an algorithm for recommending movies, or routing delivery vehicles, or a social networking site, you’d better get ownership negotiated and written down.

On a few occasions I decided that I wanted to develop some general software to use on the current project and also to keep for future use. To develop that, I turned off the clock and turned it back on again when the generalized part was finished. This was provided for in the contract.

There’s a legal term called “work for hire” that, in the context of copyright, means that whoever hired the work is the author. That’s usually the way you’ll work, whether you’re an employee or contractor, and you can go ahead and put that term in your contract. If you want any other arrangement, you’ll have to be careful, and in that case you probably do need to get a lawyer involved.

Anyway, as I said, in most cases you should put aside any idea that you’re going to get something out of the project other than your pay, a satisfied customer, and the possibility of more work. Trying to stake a claim on IP gets very sticky and it’s most unlikely that anything valuable will come out of your project anyway.

If you think some of the general code you write might be useful, you might get away with a clause saying that any code of a general nature that isn’t application specific can be used by you on other projects, with no payment required. Many clients will agree to that. If they don’t, do it off the clock, as I mentioned.

In the patent dispute that one of my friends got into, the problem was that he wanted his name on the patents, since he was the inventor, which was OK with them, as long as the patents were assigned to them. He didn’t agree with that. As I said, nothing was written down. In the end, they filed the patents without his name, claiming to be the inventors. Legally, I have no idea whether this was correct, being somehow related to work for hire. It was never litigated. He just went away angry. Amazingly, this was the second time this guy had gotten into IP troubles, both times without a written contract. Obviously, he doesn’t listen to my advice. You should, though.

Watch Out for License Entanglements

Some of the software incorporated into the application will be owned by neither you nor your client: third-party packages such as PDF-generating libraries, executable files you invoke and ship with your product, and JavaScript code like jQuery. Most of this will be covered by some sort of open source license, such as the MIT, Apache, BSD, GPL2, Lesser GPL (LGPL), or GPL3 licenses, which are the five I encounter most often. There are commercial licenses, too, each of which is different.

Each license places requirements on the user of the software, ranging from including a copyright notice (MIT) to making the source code of your own application available (GPL3) to paying a royalty on each copy deployed. You’d better know the ins and outs of each component you use.

If at all possible, use only third-party software covered by the MIT, Apache, BSD, or LGPL licenses. Commercial software should be avoided unless it delivers functionality that’s impractical to provide any other way. GPL2 and, especially, GPL3 software is hazardous if you’re going to incorporate it in your own system, as it may obligate you to do something you and your client don’t want to do: release your code to the public. However, if you’re only going to connect to it (MySQL) or run on top of it (Linux), you don’t need to worry. The installation has to be licensed for that, not the software developer. Most of the time I use commercial hosting services that provide MySQL and the operating system (usually Linux), so there are no licensing issues for them. I just worry about the source code I incorporate into my PHP programs.

Involving a Lawyer

There are some cases when you need a lawyer, such as when you want to own the IP you develop, but that’s rare. You usually don’t need one and, even if you use one, he or she can’t help keep you out of legal trouble.

Here’s why: if there’s a dispute over a written contract, it’s almost certainly going to be over what is to be developed, whether it meets the acceptance test, and when it’s to be delivered. And all of those are specified by you, not by your lawyer. Following is a typical paragraph from a contract drawn up by a lawyer:

Guess who supplies Exhibit A, you or your lawyer? Your lawyer will have no idea what any of it even means. As an expert witness, I’ve seen this in contracts involving AT&T, IBM, Microsoft, and a couple of other, much smaller, companies. The big guys used the most expensive, most prestigious law firms in the world, and there’s no question that they put well-qualified lawyers on those accounts. But none of those lawyers knew what operating system kernels, nonuniform memory architectures, virtual device drivers, or hazardous waste manifests were. Yet those were what the fights were about.

So your lawyer will charge you $300 an hour (or more) but won’t keep you out of trouble. Use a lawyer if you need anything special of a legal nature, such as that involving IP, but you’re on your own for technical matters.

Invoicing

Every project needs to have a written contract, even if it’s as simple as an e-mail outlining the key agreements. Unless you’re working as a volunteer, as I was on the Conference on World Affairs system, those agreements have to include the following:

• How much you’ll be paid.
• How often you’ll invoice the client.
• When the client will pay the invoice.
• Who exactly gets the invoice.
• What special codes you need to reference, such as project number or supplier number.

Don’t be surprised if whoever hires you for the job doesn’t know the last two. If you don’t find out the answers, you might send several invoices to accounts payable before you discover that they needed to go to project disbursement. Even then, you might find that if you leave off your supplier number your invoice might simply be ignored. Getting a call from a friendly person who offers to write in some key piece of information is a luxury you can’t count on. Many organizations welcome an excuse to delay payment. Try not to help them out.

I’ve always worked by the hour, never on a fixed-price contract. By the hour you’re on the client’s team. Working at a fixed price makes you an adversary, with every requirements change or bug report being an occasion for disagreement. Don’t do it.

How much per hour? It depends on who and where the customer is. Fees in Albuquerque or Boise are probably half of what they are in New York or San Francisco. Fortune 500 corporations pay much more than mom-and-pop operations. In fact, charge less than $125 or so per hour and a Fortune 500 corporation won’t even hire you, because you’re obviously unqualified to do their work. I’ve on occasion given a discount if a certain amount of work was guaranteed, since I knew that I wouldn’t have as much downtime while I was looking for my next gig.

Expenses—travel, equipment, software, and so on—should be extra, if possible. The Richardson School District couldn’t justify paying travel for an out-of-state contractor, so for them I rolled travel expenses into my hourly fee. That was fairly easy to calculate because we had agreed on two two-day trips a month.

Find out what documentation you need for expenses, what the limits are, and, in the case of equipment, whether and when it has to be returned and to whom.

Do whatever you need to do to find out exactly where the invoice is to be sent and how (e-mail, PDF, a corporate-vendor web site, etc.). And make sure you have all the reference codes you’ll need so they’ll know who the invoice is from and that it’s authorized. (More about this in the next section.)

Get your invoices in promptly. I had a client go bankrupt once and never got paid for my last invoice because I delayed sending it in for a couple of weeks.

Collecting

You would think that if you submitted a proper invoice the client would send you a check, right? It doesn’t always work that way, as it didn’t in the following cautionary tale.

I was working as an expert witness for a large Chicago law firm whose client, Microsoft, was being sued for breach of contract by another software company with which it had a joint-development contract. I was directed to send my invoices to the law office, which I did, and the first two were paid on time. But, starting with the third, nothing.

The law office told me that they shouldn’t have even paid the first two, because they were supposed to go through Microsoft’s legal-services system, and that’s what I would have to deal with thenceforth. A few days later I got an e-mail with the signup information for something called MS Invoice.

I went to the web site and started filling out the forms but got stuck because I didn’t know the PO number. Several e-mails went back and forth in an attempt to get it, during which I was told to use DataCert, not MS Invoice. Logging in to DataCert took more e-mails, one of which asked me for the name of my Microsoft contact, which I didn’t have. (I spoke to no one at Microsoft during the case; expert witnesses generally don’t speak directly to the party they testify for.) I read in the instructions that there was a substantial fee to use DataCert to cover setup costs. When I complained, I was told there would be no fee. There was also a dense, multipage legal agreement to sign. In the end, I signed the agreement and took their word that there would no fee.

Once I got into DataCert, I needed a Matter Number, which I also didn’t have. More e-mails to get it. Eventually, after weeks of this going back and forth, I was able to get my invoices recognized by the system, at which point I found out they would be paid in 90 days. I did eventually get paid everything they owed me, but, aside from those first two invoices, the total wait for invoice three was about six months.

So watch out if you’re working for a bureaucratic outfit like Microsoft. I don’t know if its ridiculous scheme is a deliberate way of improving its cash flow, or if it’s just complexity gone mad. Either way, getting paid was a challenge.

To add insult to injury, Microsoft specifically forbade me from billing Microsoft for the time it took me to bill Microsoft. Thus, several hours of my time went unpaid.

(In case you’re curious, I never did find out what happened with the lawsuit, as it was settled out of court, as most are, and the results were kept secret. I asked my lawyer contact what happened, but he just laughed and said he couldn’t tell me.)

The lesson: An agreement to pay you so much per hour is good, but in and of itself it won’t get you paid. Find out what you have to do to actually get paid, or you’ll wait a long time.