This page last changed on Jan 12, 2012 by conadmin.
Mike’s Rules of Software Engineering
What follows is an attempt to condense my years of lessons learned (often the hard way) into a set of simple rules. The hope is that you will find them useful and maybe it will let you learn from my mistakes (instead of your own).
Making a quality product
- Quality code is portable, secure, easy to debug, and flexible enough to be used in ways that were never intended. These are not unrelated traits.
- Your code will be used in ways you never thought of…plan accordingly.
- If this isn’t the case, then you’re probably not writing very good code.
- Kludges that we’ll fix in the next release never get fixed in the next release.
- If you donʼt do it right this time, you (or some poor bastard that replaces you) will have to do it right later.
- It always costs more to do it later.
- You wonʼt have any more time in the schedule for the next release.
- You wonʼt have any more funding either.
- Nothing is free, coupling might save you time now, but it will come at the cost of more time spent on the inevitable rewrite that coupling assures.
- Plan as if every programmer who will interact with your code is an idiot. Then you have the worst case taken care of. If theyʼre not idiots then itʼll just be that much easier to use.
- Comment your code as if you were going to have to pick it up and use it again in 15 years.
- Better yet, comment your code as if you were at the early stages of early onset Alzheimer’s
- Your code is not finished until you’ve tested it.
- Never assume the other guy tested his code.
- Consistency is often more important than doing it the best way. A less than perfect coding practice that is done consistently the same way is usually better than solving the same problem in “better” ways differently each time.
- If you can’t settle on one way of doing something, do it both ways and make it a configurable option.
- Try to design things so that likely coding mistakes can’t happen (e.g. don’t make the length field in a TLV include the size of the TLV header, or some jerk will not account for invalid lengths).
- Clever code is bad. Clever code means it is unclear, non-obvious, or otherwise obfuscated. The benefits almost never out weight the costs here.
- On the rare occasions when they do, document accordingly.
- Debugging a piece of code is about twice as hard as writing that same code. If your code is as complex as you can manage, youʼre no longer qualified to debug it.
- Time estimation is really hard…it will take longer than you think it will.
- No really, even if you take rule #15 into account it will still take longer than that.
- The majority of time spent on a project by developers will not be writing code (go on, keep track of it if you donʼt believe me), it is spent on tasks that programmers are not as good at like debugging, or testing.
- Itʼs usually best to turn these non-coding tasks into at least coding assisted tasks. This means writing code to help debug your code (asserts and test routines) and writing code to test your program (regression testing etc). This way programmers that are good at programming can translate some of that into being good at debugging and testing.
- You still have to get good at debugging and testing.
- The night before its due is probably not the best time to start integrating your code in a large project.
Working in a group
- You can be really good at your job, and a jerk, or you can be so so at your job and a really nice guy…you cannot be a jerk and bad at your job.
- In general, meetings are the opposite of getting things done.
- Anyone that repeatedly declares things impossible should find their way to your kill file.
- In programming, style is substance too. Consistent style improves code readability and makes the code more manageable in the future.
- Its less important that a project has the style you like than it is that a project have a consistent style that everyone uses.
- Laziness and incompetence are contagious.
Managing engineers (or being a team lead)
- An engineering manager’s job is to do all that is required to ensure that his engineers can do their job. This usually includes keeping his engineers sheltered from politics or any other “outside world” issues, so all they have to think about is coding.
- Good engineers are harder to find than most people think, if you have one, do everything you can to keep them.
- The same goes for good managers.
- Engineers that think lack of documentation is job security should be fired sooner rather than later (otherwise you’ll make them right).
- If you force developers to be more accountable for the bugs they cause, then the bad programmers will spend more time fixing bugs, and less time adding more bad code to the project…(a self limiting problem).
- A good exercise is to make your engineers swap code with each other…either you’ll get better code out of them, or they’ll kill each other…either way it should be fun to watch.
- You get what you pay for. If you think that less skilled or unexperienced engineers will do the same job as more experienced engineers then you are very mistaken. You might pull it off for a release or two, but sooner or later the real bill will come due.
- If it can be made non-interoperable, it will be (e.g. IPSEC).
- RFC’s are just a jumping off point to start negotiations; protocols are almost always implemented differently.
- Don’t trust any RFC with updates on April 1st (e.g. IPSEC…jerks).
- IEEE specs are worse than RFCs.
- ITU specs are worse than IEEE specs.
- Any time you use open source code in a project, be prepared to maintain your own branch of that code. You never know when the developers will get bored and leave you hanging.
- Be careful how you mix your licenses. Using GPL’ed code everywhere might speed up your startup’s time to market, but it could all be for nothing if your code ends up being forced into becoming GPL.
- If youʼre not adding much to the GPL that youʼre basing your proprietary product on, then sooner or later people wonʼt bother paying for your code at all. You have to have something of value to add.
- Beware of anyone in a suit.
- The man in charge often didn’t get there by being better than everyone else; keep that in mind.
- That doesnʼt change the fact that heʼs in charge.
- If you’re made responsible for something (like security) but you are not empowered to make sure it happens, then your real job is to be the person blamed when something goes wrong.
- Engineeringʼs job is to find a way to say yes; even if the request sounds (or is) stupid.
- If the request sounds stupid try to get to the root of what theyʼre really trying to do, often youʼll find that they are thinking too far ahead of themselves and a simple solution exists.
- Saying yes to the project does not mean saying yes to unreasonable or unrealistic timelines or resource allocations. You still have to set expectations appropriately.
- Saying yes also does not mean keeping your opinions quiet. If you think they are going down the wrong path, tell them so, but be prepared for the fact that engineers rarely call the shots.
- Keep your code for work very separate from your code for personal projects.
- Be careful not to use work equipment for private projects either.
- Don’t work any harder than you will be rewarded for.
- There are many types of rewards, how you define that is entirely up to you.
- Don’t ever let your company make you do something you would not be proud of; you may have to work with them now, but you’ll have to live with yourself and your reputation for the rest of your life.
- If your company makes a habit of asking you to do something you’re not proud of, find a new job.
The business of selling software
- Management has no idea what the customer wants.
- Engineering has even less idea what the customer wants.
- If you don’t talk to your customers to see what will make them happy, then sooner or later someone else will.
- “Cool” is not a business case.
- Demonstrating that your competitors suck isn’t enough to get anyone to buy your product.
- Don’t ship anything you’re not proud of.
- Never outsource your core competency.
- In general, “revolutionary” products, arenʼt.
- It doesn’t matter how secure your product is if no-one is willing to use it.
- The same goes for just about any feature or aspect of your product.
- Chances are your customers/users are not as dumb as you think they are.
Dealing with a crappy job
- “Working from home” doesn’t count against vacation time.
- Only listen to the boss that can fire you, the others are just useful for stopping bucks before they hit you.
- No-one notices when you come in early, management always notices when you stay late.
- No-one cares if you read Wikipedia all day every day if you get your work done on time.
- If they do care, find another place to work.
- Your best guys probably wonʼt waste most of their time if you gave them something more challenging to work on.
- Never commit to anything in emails that you’re not actually committing to, if you must, commit to it over the phone or in person with no witnesses…otherwise learn phrases like “I’ll look into that” or “we’ll see what we can do”.
- If its been done before its boring.
- Odds are (java/soap/haskell/other wiz-bang thingy) won’t be as revolutionary as you think it will be…C is still alive and well and not going anywhere…so is COBOL for that matter.
- That doesn’t get you out of having to keep up with current trends. They might not be a revolution, but they might not go away either.
- 1.0 rhymes with “oh no!”
- Strive to make a really good 1.0, then move on to other, more fun projects…you’ll still get all the glory for that first project, but you won’t have to do the work anymore.
- Use the language that you are most comfortable with, even if its not a perfect fit. Its often faster to make the language fit the developer, than to make the developer fit the language.
- You can take this too far, (perl programmers, I’m talking to you!)
- This doesnʼt mean that every programmer on the group gets to use their own language. At some point this has to be decided as a group who will use what.
- Contrary to popular belief, third party libraries reduce portability of your code.
- Open source code is filled with bugs.
- Closed source code is even more filled with bugs.
- If you’re not getting better, you’re getting worse.
- Writing a technical book is way more work than you probably think it is.
- Bugs exist in the space between what a program is supposed to do and what a program actually does. There is no such thing as self documenting code. Yes the code tells me what the program does, but it can never tell me what the program is supposed to do. Comments should explain what the program is supposed to do in as much details as the code explains what it really does.
- From time to time every rule must be broken; one of the tests of a good engineer is knowing when those times are.
- The best engineers know when to break the rules, but they also know how to compensate for the resulting problems (documenting more, making it an idiom, etc).