I’d been meaning to write something like this for a while, and another thread reminded me to do so. Ideally, for anyone out there who has to work with programmers, this will aid you in getting something that works, on time, on schedule, and on budget.
At heart, the first thing to do is to get rid of the image of a “program” as, for instance, Internet Explorer. Yes it is a program, but when you think about programs, from now on you should think, “Automobile.”
Now, imagine going into a Quicky Lube and going, “Hey you all are car people, how about you make me a car, I’ll buy you all the equipment and parts you ask for. I know you’re all engineer people, so just tell me what you need and make me proud!”
Yes indeed, flashing red lights aplenty.
Now, there’s no saying that some guy working at a Quicky Lube isn’t some insane car engineer who hasn’t yet had a chance to break into the industry, but the odds of that are pretty low.
Now unfortunately, the programming industry isn’t like the car industry. There isn’t a Quicky Lube of the industry, nor a Ford, nor a Lotus. Certainly there could be such in the future, but for the moment there aren’t NASCAR races between programming companies, the people who get the end product don’t have any idea how fast it should run, or why it seems to have way more buttons and entry boxes than any reasonable human could ever need or such. So, overall, there’s been no way to separate good from suck.
So, pretty much, you have to always assume you’re going to get the guy from Quicky Lube, unless you know programming yourself and can quiz the guy.
Which brings us to an issue of hiring outside contractors. Almost always you’ll be mostly dealing with the sales people of the company. This is BAD. Before deciding to hire the company, find out who will be actually writing the program,* and interview him. If you know any programmers who are comfortable with C or C++, have them interview the guy.
So, tip #1) Make sure you’ve talked with the actual programmer and made sure he at least seems up to the level required by the importance of the task. Assume that otherwise you’re going to be fed some guy who (in automotive terms) only knows how to press the gas and break pedals, let alone manufacture a car from scratch. And no, I’m not kidding. I’ve had to work side-by-side with some of these.
So, getting back to our Quicky Lube proposition, we’ve asked them to build “A Car.” Well, in real life there’s lots of different things falling in the range of “Car.” These could include anything from The Little Toy Car your Child Plays with, to the M1 Abrams Combat Tank, to the Porsche 911.
If you go to a programmer and say, “I want a database system for keeping track of my customers.” then that’s bad. I mean true we’ve gotten a little bit specific, but still I can’t walk up to a auto engineer and say, “I want a tank for winning wars!” True, he might build you something that is useful, but the odds aren’t real high. There’s a whole lot of specifications that he needs to know–at base minimum how much time he has to do it in, and what sort of resources you’re going to give him to do it–as well as the specifics of what kind of tank you want, how many weapons it should have, how many people it can seat, whether it should be amphibious or not, etc. etc.
If you ask a guy to build a tank for you, and you needed an amphibious tank, then when he shows it to you for the first time and it quite obviously isn’t what you were needing, then you have to re-engineer it. He might have built something that was light enough that simply making it water tight will make it good, but he might have built the mother of all heavy-duty assault tanks and essentially he will have to entirely restart from scratch.
This is why you need to think in terms of cars, rather than Internet Explorer. IE may look like a bunch of buttons which can be moved around anywhere you want, and clicked in any order, and you should be able to just add and subtract and move about functionality to get what you want, but in reality, the sucker is engineered just as much as a car. You can’t say go to Ford and say, “Ya know, I think I would like it better if you put the steering wheel in the middle of the dashboard.” If Ford tried to comply, they’re either going to have to rebuild the entire steering system (moving around the engine, disrupting the cars balance and the cars shape, which could impact the aerodynamics) or they would have to put some cludge into the dashboard so that the steering column did a zig-zag to meet back up with it’s old base.
One or two cludges is fine, but the more cludges you add, the greater the odds are that the whole thing is going to flubber itself up the butt and either be very unstable, or needing to be entirely rebuilt from scratch.
So, tip #2) Yes, it is boring and yes you will have to lower yourself and potentially spend days going over designs on paper and meetings with the person who will be doing the programming, but in the end, you’ll be a lot happier. Yes, after he makes it, there may still need to be some “fixes” (cludges) put in simply because you can’t anticipate everything, but having a solid design at the beginning will make that become a non-issue.
Again, back to our Quicky Lube fellows. We’ve asked them to build a car without saying how long they have to do it. So we go back to ask them and they say, “Oh, we can get something for you in 3 weeks!”
What this means is (since they haven’t received any sort of design parameters) they think they can make a bare minimum car in that period of time. Most likely it doesn’t include making sure the thing actually works.
This is another reason to make sure that there be a specific design. If I want a carved statue of a car, then so long as I get back something that looks like a car, I’m fine. But if I want a tank, every single system in the car has to be rigorously built and tested to make sure that even if you put the vehicle in 100[sup]o[/sup] heat, and riddle it with holes, it will continue to function as reasonably as required for it to service as a military vehicle.
You can’t dictate the schedule and expect to receive a vehicle that lives up to your specification. Nor can you expect the shedule to match anything in real life if you don’t give the engineers a specification that they can look at and tell you how long it will take.
So, tip #3) Hash out a full design of the program with the developers (as per tip #2) and afterwards ask how long that will take to build. You might have to then go back through the design and remove features because they can’t be accomplished in the time frame you want. Once you are done, in general you will want to muliply the build time by two; this is the build time plus verification, fixing, and modification time. For military or government work, probably you want to multiply more by something like 2.5 since generally the code needs to be tougher.
Now, when it comes to verifying the program, we have to get away from the car analogy a little bit. Cars, unlike programs, aren’t needed to be assumed to be put to abuse by evil minded miscreants.
If someone wants to break their own car into little bits, that’s their money down the toilet. However, if at the heart of every car engine was a nuclear reactor capable of blowing up the earth, people are going to care less about the handling, and a lot more about making sure people can’t hack into their own car and destroy life as we know it.
In the programming world, most generally this “nuclear reactor core” would be something like a database full of all your users’ credit card information. The program doesn’t need to just work as a program, it also needs to be proof against “bad people” and simple human error that can mess up other people (for instance, by accidentally emailing people’s credit card information around to the wrong people and such.)
Generic testing can verify that the code won’t accidentally do something stupid at the wrong point and mess people up. The best way to achieve this (assuming you have the time) is to ask for a “function level test of any conceivable parameters and their results (and that inconceivable parameters can never make it.)” Which in automotive terms is essentially the same as asking to have each part in the car to be individually stress tested. Other than that, you will pretty much have to rely on the development crew or test crew to do their bit in trying random stuff against the program. But what you can do is…
Tip #4) Set up scheduled keystones during the design phase (see tip #2) at which you will be able to interact with the developers. During the build phase this is pretty much just a chance for you to verify they’re actually building stuff. They should have given you in the schedule what parts should be “demo-able” by what time, so watch those demos (you don’t really need to do any more than that.) During the verification phase, however, you should be receiving working versions of the app at scheduled intervals, which you should verify against the original design specification.
Now, if the application does have some section that needs to be secure, then firstly you have to get the “function level test of any conceivable parameters and their results (and that inconceivable parameters can never make it)” at least for the relevant sections of code. You should also have the developers compile a list of “attacks” that are relevant to the system (be it encryption, database queries overruns, buffer overruns, etc.) They then have to test that the system is proof against all of those (within reason of course, given the importance of the information and such.)
And so overall summary tip #5) Make sure you know your programmers, make sure they know the specification, make sure they can get the stuff they need from you to do their job, be it artwork, or answers to questions on the design, have a clear schedule that is agreed upon by both parties based on the amount of functionality in the specification, and make sure to specify the level of robustness of the code and what sort of testing you require. Do all this with the person who will build the application not the salesman, and make sure that person isn’t sweating profusely when being asked to sign off on the schedule and specification pair.
Happy Contractoring!
- Or the lead engineer for the project (the managing programmer) if it’s going to be a team project. You’ll have to assume his guys can do as well as he is willing to schedule for them to do.
