No Way To Run Things
This will be a cautionary tale, of how not to run things in various ways, as the title implies; of how sleazy people can be, or desperate if they're in financial trouble; of hubris and bubbles not just being for tech companies; of getting things clearly in writing; of noticing signs of trouble in other than hindsight; and of having correct expectations and managing a programming project both as a customer and as a developer being hired.
In 1999, I had left my support job to join the business full time. We'd been around in a sense since 1996, working out of someone's house. We got the office at the beginning of 1999, because the big client I always mention had hired us to be on call for support 24/7, and just happened to own the building and have spare space too.
There we were, my partner who had gone out to work full time for the company a year before, me, and another partner. At the time, we were still doing programming and Oracle DBA work for a rather strange client in Providence. We also had a programming project going for the big client, and support for them, and odds and ends.
One of the people who had worked for me at the support job in one of the last new hire groups got a job around the corner from us. I was even a reference that helped get him hired. Around late spring he started asking us about working on a project for them. The company was a distributor and manufaturer of eyeglass frames, which I never knew was such a huge business. Ultimately, their downfall may have had something to do with it wasn't such a huge or glamorous business.
So we eventually went on over and met with my friend, who we'll call Art, and his decidedly type-A boss, call her Dawn.
The good thing was my partner and I were perfect together for this kind of thing, which is a reason I'll miss him. Dawn was all about business needs and concerns. My partner is all about technical. She and I spoke the same language. My partner and I spoke the other same language. Art spoke in the realm of whatever would please the boss and juggle the job into staying intact and favored, a skill I'd never seen him have at the previous job.
What they needed was a program to assign and track IT department "projects." A project could be anything from adding a field to a table, to a major programming project; from fixing a computer, to ordering and setting up a new server. The basic idea could be adapted to any IT department or similar organization, such as a support department or company, where it could be modified into something like Clarify to track support incidents.
The plan was for Art to come over and work with us on it part of the time. That way someone who knew what they needed would be intimately involved, plus it wouldn't take as much work by us at the agreed rate of $100/hr.
The program would replace a cheesy Access database application that only the guy who created it, no longer employed there, really understood it. The new program could be deployed to anyone who might need it. A user would enter a work request/project description. There would be the ability for their manager to approve it or not. There would be the ability for the IT manager, Dawn, to have master control of everything, and would be able to assign tasks to specific employees.
The tricky part was queuing. They wanted to have things order by date oldest to newest, and by a priority assigned, and then also allow an override to take anything the IT manager wanted straight to the top of the queue. She also wanted to use it to a degree to help determine and allocate costs, based on estimated and actual time for the project and an editable number for each employee, based on total labor cost including benefits, again under her control. This would make it easier for managers to see what a requested project would cost their budget, and be able to cancel or modify it if desired on that basis.
The thing listed all the employees, and their type or department. Permissions were based on that. Anyone could add notes for a project, which was a great way to advise on status or keep other IT people who might have to pick up on it up on what had happened to date.
The strange thing at that meeting, which was not the first time we had discussed things but was where we agreed to go, was how they wanted to pay us.
To sneak the project into the budget as not a capital project for either budget or IRS purposes, they wanted to treat it as if they were paying consultants. Didn't matter either way to us, since we were billing by the hour anyway. They wanted us to bill weekly, but I ended up billing monthly because it was more convenient and what I was used to doing.
Finally, our standard terms were net 15. Their standard terms were net 60 and that wasn't easily circumvented. They agreed to net 45.
We started out with nothing in writing, just a basic proposal outlining what would be involved. That proposal was, of course, too vague, entirely apart from not putting key things in writing and legally signed.
Off we went. My partner did most of the work. Art was theoretically doing the user interface in conjunction with my partner doing the hardcore coding behind it. I did a lot of testing, sanity checks, and consultations on the design. We hired Bob, at the customer's request, to help work out the code for queuing. I was the only one of us the whole time who truly grasped what the queuing was trying to do and what needed to go into it. Probably I should have written that part, scary or not. I explained it to both my partner and Bob repeatedly over the course of the project, and each time they thought they had it. Mostly my job was managing things and keeping an eye on progress and whether the features were what they ought to be.
To make a long story short, Bob's code wasn't precisely what we needed, and was so out of context, being written separately, that we ought have not farmed it out. Worse, it was better and closer to what was needed than my partner thought it was, so his horror when he saw it was overblown.
Art used his time over here, when the company actually let him get away, which was about half what they were supposed to allocate, as much as a break from the stress of his job as to do any work. When he was working with my partner, he was as much distraction as help, and apparently the part Art did was largely redone by my partner. Nor was he useful as an agent of the customer to ensure they knew how things stood and were happy with it.
My partner was too much the co-boss to allow much real supervision, and I was increasingly hands off as a result of that and his moodiness. In fact, what I accomplished that was particularly useful was frequently keeping Art away from my partner so he could work more concertedly. I humored Art's inclination to show up here to work on the project, but to use the time relaxing and gabbing incessantly. He'd talk with me for a couple hours and then it would be time to leave, which Art would do feeling that he'd successfully dodged the pressure cooker of his job for a couple hours.
They were very concerned with the total cost being under $20,000. That was always a stretch. However, my partner signed up for a full time job elsewhere and "finished" the project to a point where the basic functionality could be deployed. Internally they could add reports and tweak some of the other details. He spent most of a few days over at their offices to actually make sure it worked with their database and Art was well established toward deploying it.
The program rocked! I still think it could be bootstrapped easily into something people would buy, or be used as a template for a customized version for every customer.
About a month went by...
Then the customer came back at me full force. It didn't work. Where were the reports. It couldn't be deployed. Wouldn't really even run. We'd given them garbage. This was spearheaded by Art, who in fact had made extensive modifications to the code and broken it! The only honest point they had was we'd not created reports. This should have been a relatively easy thing for one of their IT staff to do without paying us big money, so in having them do it, we were keeping them below the total they'd shot for. It ended up coming to just over $19,000, most of which we hadn't received yet when the first "delivery" was made.
Oh, when they came back at us with the broken code, I gave them a 10% discount on all previous and future work, and adjusted accordingly. The grand total reflects what it all came to after that discount. That was fun. They blamed my partner for fleeing. Which meant I, not too happy anyway because we'd almost gone out of business as a result of his departure, blamed my partner. Even with the fact they broke it, because a less hurried completion and internal beta deployment would have allowed my partner to ensure it was bulletproof. I took his word that it was, which may or may not have been true.
Since my partner was employed elsewhere, Tim and I started debugging. I assigned the reports to the partner who had moved to New York and needed the work.
It turned out that Tim and I made a great team, debugging and fixing code, discovering that it had been changed. When my other partner saw it he recognized that immediately as well.
The problem was we would spend all day fixing sections of code and making swaths of it work (again) as intended. Then my partner would show up after his job, decide what he had originally written in those swaths of code was crap, delete it, and rewrite whole segments from scratch to be better.
We were not amused.
It was basically making all the work we'd done pointless, and it was taking a job of repairing and turning it into partial rewriting.
In the meantime, out in New York, the reports were bogged down by the customer who demanded the reports not being able to tell us what they wanted! Eventually that got worked out enough to have a handful of important reports created and able to be incorporated. The thing is, the NY partner put in for easily twice the time I was certain it should have taken. I couldn't imagine it taking that long no matter who'd done it.
I was not amused.
I added in the reports. We got everything done. It still had to be deployed, but Art really was capable of doing that. We had a nice, working program, with the queuing working as it should have and everything, done by their deadline, and a bill handed in. For another $21,000 on top of the $19,000 that "completing" it had come to originally.
They now owed us something like $30,000.
They were as much as 120 days. So much for 45.
You know where this is going, don't you?
In the early part of the last century, this company arose that made and sold eyeglass frames wholesale.
The company gradually grew. It ended up being owned by four guys, each in a key executive position. The COO was the boss of the IT manager we dealt with, and was one of them. The project wasn't completely surreptitious, as it had required his approval. Eventually they decided that they too could overextend and be sexier than they were, in the nineties, like an internet bubble company. They bought a line of designer frames for far more than it was worth, and expanded in a way one might not, casting an iota of critical thought on just how much demand that industry might represent, have considered wise or healthy. They were most impressed with themselves.
Even as they hired us, they were in trouble. The signs were there. Pay in 60 days. Actually take longer. Manipulate what is recorded as current or capital expenditure. Have staff that is too busy to function well because you can't afford to hire. Have managers being sneaky about how they get things into the dangerously creaking budget. Have key people fleeing like rats from a ship they know is going to sink.
The IT manager succeeded in shaking the tree and getting me all but that last $21,000 before she unceremonious fled. Somewhere along the line, the COO either got canned, fled, or got removed from that job and kicked into submission.
After the IT manager left, Art was largely on his own, with less direction. This was good in that he could find more time to work on deploying the project. After the final final delivery, he started pestering me with crazy deployment problems. He seemed to have forgotten everything he knew about basic troubleshooting, or else it was easier to ask, and blame, someone else. I found solutions on the web. He pleaded inability to make them work. I did a little testing and tried to help, but we were no longer billing them, and I was sure they were about to default so I wasn't as enthusiastic about helping as I might have been.
Then he got laid off. We knew that was coming, because we knew the company was imploding then.
That left me with nobody there who'd actually been involved, nothing signed, and just a name of someone in accounting to pester. After a lack of responses, I sent return receipt and signature mail.
That got me a chat with the CFO. A new CFO, mind you, there to try to pick up the pieces. He flat out refused to pay, claimed the program didn't work, had never worked, was junk, couldn't be used. Threatened to go after us to recoup the money they'd paid if we pushed the issue. I'm told that's just bluster.
Knowing they were bordering on bankrupt and we had nothing in writing, and nothing to file a UCC against, I let it go. It hurt. We never really recovered from that. It cost more in labor for that project than we received. My partner's confidence was hit by it, like a repudiation of his work. It left two of us mad at him for what he'd done both calling things a wrap prematurely and fleeing, and then for ruining our great work by needlessly ripping out and rewriting sections of debugged, working code. It left my partner thinking Bob was incompetent. It left me mad at the NY partner for what I was certain was milking the hours to be what he wanted to make, rather than what it actually took. It left us all mad at our former colleague, Art, who was more of a politician and manipulator than demonstrably a good programmer and tech person at that job.
Within a few months, the company was bankrupt. It operated for a while that way, then closed, leaving an empty building for a couple of years.
Can you see there are some lessons here? The title refers to both companies in general, as well as the project between them.
Get things in writing, at least for something so major.
Use good project planning and techniques such as those found in the book Rapid Development.
Things that are in writing should include clear payment terms and recourse if violated.
Things that are in writing should include complete project description as much as possible.
Things that are in writing should include clear deadline(s) and recourse if violated.
Deadlines ought to include both project completion and benchmarks.
Things that are in writing should include clear indication of what conditions satisfy delivery and eliminate any reason for failure to accept as such.
Be careful with, or avoid, arrangements where you work directly with an agent of the customer on a project you are responsible for, but he can affect adversely.
Be aware that custom software projects are costly.
Be watchful for indications that the customer you are about to commit to is in financial or leadership trouble.
If you are having custom software created, allow the developers adequate interaction with your people to be sure of what you want, and that it is going the right way as things progress.
Don't let your acquisitive eyes grow bigger than your wallet, market, or industry can bear.
Don't commit to projects or purchases you have real reason to believe you can't pay for.
If operations can be made efficient with a little sacrifice, let it happen rather than hamstringing the people who can make it so for short term reasons.
Avoid arrangements where unaccountability of any given person working on a project, or for you in general, is possible.
Make sure everyone in a project starts and stays on the proverbial same page as needed.
If things aren't right with work you had done, report it immediately, and make sure the "problems" are not something you caused but are blaming on the vendor.
Completion should be clear, definable, accepted by both parties ,and when accepted, not reversable.
Don't back away from managing things just because people are a little difficult.
I may not have all the points I want to make from this here yet. It's raw as I first post it, and will be subject to editing between now and Monday morning. Once it seems complete, feel free to point out any lessons I might have missed listing, or worse, noticing.
Except eliminating a word I'd typed twice, I have made no changes, but do have more observations and followups to mention.
When code has been written, tested, debugged, fixed if there was a problem and it now works as the customer expects, it is done. Don't arbitrarily change it. Don't tear it down and start again because now you see a slightly better method of accomplishing the same thing. Save it as a lesson for similar software in the future, or an upgrade of this one in the future. Writing it again without good cause and
charging for it is as much fluffing the bill as it would be to charge twice the time you actually put in.
I long since got over the stiffing. It still hurts, and still affects us, but it's only money. I can look at is as a valuable experience. I can figure that if you take out excess hours for reports and rewriting code arbitrarily, perhaps the amount ought have been more like $12,000 than $21,000. I can figure that sitting on a couple drives and CDs around here is code for a program that we own free and clear by dint of the company repudiating it, the company not paying for all of it, and the company long since having ceased to exist. It may have value if we wanted to try to pursue it. I have sometimes wished I had such a program just for internal use. Go figure.
The eyeglass frame company is representative of a problem I believe exists in many businesses. The urge to growth. When you are in a mature business or industry, doing well, steady profits, but it's just so damn
boring, it's possible to grow yourself into trouble and take a good business down. So take that to be my major "oops, too late" bit of advice for the company that hired us and then went under, and any companies like it.
Sometimes you just have to be what you are. If you do look for opportunities when you're at mature stability, be careful. In geological terms, it might be like an ancient, meandering, venerated river hoping for an uplift event to turn it into a canyon-carving, rapids-laden torrent so it can be special. It may simply not be in the cards. Or the plates.
MORE...
