Poor Ways to Run Business on Software

1. Use Crappy Products from Crappy Vendors

So there was a sales team with uniforms, hard handshake and rocking flash/powerpoint demos that fooled you into a crappy product. You also agreed to pay them outrageous amount of support $. Later you found out it is impossible to tweak and you call them to help. You have to pay them additional $200 an hour for consultants (who bill you $50 a meal). What idiot consultant will do the work right and get out? It is a recipe for pension, and their grandkids education fund.

Poor product with outrageous support cost is not good business. Know when to dump crappy products. Don't run a business on top of it.

2. Hire Consultants to do work; leave your employees fixing their work

Some people tend to believe they MUST pay somebody else to get the jobs done when they have employees themselves. Then, regular employees who did not participate in that type of work are told to maintain such work. Look, you must trust your employees being able to do new work. What tech knowhow these outsourced guys have? Both your employees and the outsourced guys look at job sites to find work. Maintaining other people's work is boring and difficult because they didn't write in the first place.

3. Set it and forget it

Informercials sometimes are fun to watch. There is some cooking machine you can set it and forget. It won't burn your kitchen. Good. This happens to old apps. Somebody wrote code, deploy it, and forget it. No one knows where the source codes are and how to maintain anything. These are probably done by consultants, what do they care.
No one can afford losing source codes, must archive them, must have build-from-scratch instructions and build files. Someone must know how old apps work. Reward people financially for maintaining good docs.

4. No room for testing

Myth: 80% design 20% coding. If you design it right you write once and you are done. Outrageous myth. When you design you are in dream mode, you don't know what you say will work unless you code-compile-run. Must let your developers code and tell you how long things will take.

But the most outrageous thing is no testing. QAs come in too late and sometimes development teams don't even have any QAs. Some QAs dare to come ask developers for unit test plans. Where is YOUR plan? Also, schedule DEMANDS delivery after 1 week of testing anyway. So what if anyone finds anything. Most often there is no time to fix stuff. Why have such stiff schedule? if schedule can't be moved, why even test?

Better approach will be test as you go. Have QA team, more than 1 non-technical person please. Involve QAs early. Have QAs test frequently. Involve in the whole process. Skim on the paperworks please.

5. Security tie hands of developers

When an support issue come in, there is usually no way to log in as the user having problem and see what's going on. This is tying your hands in helping to put out a fire. Where are the logs. Give me access to it!