Doing everything wrong - Embedded.com

Doing everything wrong

Everyone knows how to develop software—there are articles, books, and project-planning tools galore. We call it Computer Science, so there must be a science to it. In reality, most plans don't survive the first week of a project, so software engineers and their managers have invented “Rules of Thumb” to help them cope.

These Rules of Thumb all sound reasonable and most have their place in certain circumstances, but the more often you hear them the more you know you're in trouble. Here is my list of bad Rules of Thumb and other things you don't want to hear when you're developing software.

Low-hanging fruit
Do the easy stuff first and make lots of progress quickly. It sounds sensible. When it's late Friday afternoon and you don't want to break your software right before the weekend, do something simple and go home with a smile. Or there might be a trivial feature that requires building the infrastructure that everything else depends on. Once that single feature works, you have the groundwork built for the whole project, and the rest is easy.

But when “low-hanging fruit” becomes the answer to every question, it leaves all the hard things until the day before the deadline. Everyone starts to measure progress by the number of bugs fixed. Nobody wants to take on a problem that requires a two-week redesign when the rest of the team is fixing 18 bugs a week. Low-hanging fruit is a trap. Do the most important things first. Leave the easy stuff for last.

We don't believe in titles
We don't believe in titles—or business cards or real offices. Except for him. He's the Vice President, and everyone else is a Junior Engineer. Still, none of the problems are the VP's fault. Startups like flat organizational structures. It can make them more flexible. Besides, they don't have to give away many stock options to a junior engineer. But every project has a natural structure, and the VP shouldn't be managing the details when he has 20 people working for him. Some people are better managers than coders, some know the best algorithms but can't implement them, and some will write code forever as long as they don't have to talk to anyone.

The flat organization is a fad that small companies try. Big companies do the opposite and add a layer of management every time there's a problem to solve. Neither is the right answer. Instead, you should hire good people, know their strengths and weaknesses, and organize them to get the job done.

You'll be working with our team in France
It's not language that's the problem; they speak English as well as you do. It's the time zones. Every answer takes a day instead of five minutes, and it's a big deal to get people into the same room together to solve something. If your GUI design is being done in Dublin and the coder who needs it is in Boston, and all they have is e-mail and a phone, your project will never get finished. If your team in Paris (or Albuquerque) has a problem, you might not hear about it for two months. That's why small companies get things done faster. Everyone is within shouting distance. Decisions get made and problems get solved.

Can intercontinental project teams work? Sure. They have to when companies get big or work gets outsourced. They work best when projects are completely separate and have no interdependencies. The biggest issues are always communication between modules (and the people who write them), and you don't want these issues falling through the cracks. The bigger these problems are, the more you need team members talking to each other daily.

I stripped the comments out
I actually saw someone do this so he could see more lines of code on the screen at once. He was good, he had written the program, and he knew it cold. He didn't really need the comments. Afterward, nobody could maintain the code but him. He couldn't be fired, of course, but it also meant he couldn't be promoted. He owned that one piece of software for a very long time.

Now you're thinking, “How could that happen?” It's easy. Do you have code reviews? Did you ever ask an interviewee what makes a program well written? Most places think that anything that runs is “good code.” You only get what you pay for (or check for).

Sales needs this by Wednesday
Salespeople are wonderful. Really! If they don't sell, nobody else has a job. But don't let the sales department commit you to a schedule or design your software for you. That's your job.

Salesmen always have some prospect that will buy 20 systems “if we only had this one new feature.” Does he have that in writing? Customers make all kinds of excuses to get a salesman out of their face. Think about this new feature. How long will it take to develop? To test? To document? Is it on the price list? Can the support team install it? Can the sales team sell it? None of this means that you won't have to start adding a feature by Wednesday, but don't let the sales folks drive you crazy.

And don't let them design your systems. Twenty years ago I saw a system sold to a chemical processing plant. The plant had seven large chemical reactors in a building 600 yards long, and each reactor had 100 sensors and controls on it. The salesman convinced them that they could save lots of money wiring the controls and sensors “if you put a computer here, and one there, and one more” and so on. The salesman sold them twenty-three computers in all (8085s in those days, if you care). It would need a custom-written operating system to tie them all together, to be written by a team of four kids fresh out of school. Those kids never had a chance. The system never worked, and they eventually had to redesign all the software, after a year of disasters. Design systems yourself—carefully.

Let's have a meeting
Two hours of meetings every day, but you still can't figure out why you're 25% behind schedule. Have a doughnut.

What is your meeting for? The bigger the meeting, the more the communication will flow one way. Attendance should be optional for any meeting of more than five people, including the weekly status meeting, and any meeting with a conference phone turned on. Decisions get made in small meetings.

Some people spend all their time in meetings. In some companies, everyone does. Don't go. You'll get three times as much done, unless they fire you for “not being a team player.”

We designed our own programming language
Making your customers learn a special-purpose programming language to use your product is a mistake. Customers don't think the way you do, and they don't want to be programmers. Go back and think very hard about your user interface. Build a GUI for your customers, no matter how hard it is to do it right.

Don't ever design a new language for your own programmers to use. There's always some computer science jock who'd rather design a language and write a compiler instead of just doing the software directly. It's never the right idea. First, it will invariably be an interpreted language—slower than it should be by a factor of 10. Second, it won't be complete, because some normal language features won't be needed immediately. It won't be thoroughly debugged either. Finally, you can't possibly hire anyone who has used it before. Or wants to.

The new guy has a PhD in math
The new guy has a PhD in math—or something. I'm not picking on math majors. They make good programmers, as do musicians. (Former history teachers make lousy programmers.) However, a group full of mathematicians is a strange beast, because they're all taught proof-by-counterexample. Every time you suggest something, they have an example of why it won't work.

Beware “the VP who ran four different startups.” Especially if they all failed. He thinks of himself as a Professional Manager and doesn't want to know about your software. He has no way to make decisions on technical merits, and politics always wins when he's in charge.

Duck for cover when “the new boss was a professional ballplayer.” The company president has season tickets to all the Patriots' games and thinks it's cool to have a well-known athlete around. The key words are always teamwork and giving 110%. It's actually impressive when force of will can solve a problem. But when that kind of pressure just makes problems worse, life is hell.

All hands on deck
A project is so critical, and so far behind, that everyone in the department needs to stop what they're doing and work nights and weekends to fix it. A month later, that project is back on schedule, but everything else is screwed up. This guarantees that you will always have a new disaster just around the corner.

Sometimes an unexpected opportunity shows up that can't be ignored, and you have to move heaven and earth to make it succeed. This doesn't happen often. What really happens is that promises get made that can't be kept, and nobody will admit it until it can't be hidden any longer. This is always a sign of bad planning. Programmers working 60-hour weeks don't write great code and don't do much testing. Having folks dive into code they've never seen before doesn't accomplish much, and they ask enough questions to slow down the people who actually know what they're doing.

If this happens more than once or twice a year, it's deliberate. Your boss thinks he can impress the president by the flurry of activity when people work long hours. If it always comes up during holiday weekends, find a new job.

A true story
Once upon a time, in a large company that no longer exists, the sales team sold the government several large computers plus some special hardware and custom software. The contract required software delivery within 60 days of hardware delivery, with penalties of $13,000 per day if the software was late. So far, so good. The penalty provision sounded scary, but it was reasonable. After all, the hardware was no good without the software. Besides, the company had a good programmer on board who knew the requirements and had laid out a schedule.

Then two things happened. First, the programmer was diverted to an unrelated project for three weeks because that project was late. Second, and much worse, the salesman arranged to have the hardware delivered early, so he could earn his commission in the second quarter of the year instead of the third. Then life got exciting. The sales department immediately decided, loudly, that the software was going to be late, and hired a consulting company to do the same work in parallel as a backup. The $100,000 consulting fee came out of the software department's budget, even though the consultants never delivered any code. The software department put together “tiger teams” and had daily status meetings with a senior vice president in attendance to witness the heroic efforts. The managers made stealthy inquiries about the competence of the programmer in charge and whether he needed to be replaced. (He was good, and it would have been too late to replace him even it he wasn't.)

In the end, the team worked extra hours and the managers brought in dinner from the local Chinese restaurant every night, and the software was delivered on time. The secret of software development has always been good people and lots of Chinese food.

Jeff Kenton was a co-founder and director of operating systems at Xyvision in 1982. He is a consultant in the Boston area, developing operating systems, compilers, and network software. He can be reached at .

Reader Response


So . . .
You have quite appropriately 'hit' every nail on the head! I have seen instances of every one of these managerial events throughout my career!

The irony is . . . people keep repeating this stuff over and over again!

You gotta watch out . . . when those 'tiger teams' start to sprout up!

– Ken Wada
Sr. Embedded Systems Consultant
Aurium Technologies Inc.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.