Editor’s note: This is a guest post from Mike de Libero. Mike has been doing software development for more than 9 years in a variety of settings. He’s worked as a freelance developer. He’s also worked on a small team of developers maintaining 30+ programs at one time. He’s even worked as a security tester on the Microsoft Office team.
I first met Mike through Mark Curphey. Software security is a small world. The funny thing about many of the people I meet in software security is that they 1) tend to break things to make things better, 2) like to help, and 3) focus on improvement. The great thing about Mike is that he’s got a passion for development, and he’s more focused on principles, patterns, and practices, than on a particular technology. Here are Mike’s top lessons learned in software development …
Top 10 Lessons in Software Development
Here is a summary of my top lessons in software development:
- Lesson 1. All software is flawed.
- Lesson 2. Check-in often.
- Lesson 3. Tests, gotta love them.
- Lesson 4. Refactor, check-in and repeat.
- Lesson 5. Coding is easy, humans are tough.
- Lesson 6. The more eyes on your code the better.
- Lesson 7. Keep learning and improving.
- Lesson 8. Simple is beautiful.
- Lesson 9. Learn software development not coding.
- Lesson 10. Think about your audience.
Lesson 1. All software is flawed.
Anyone who has written a software program larger than “hello world” knows that there will be bugs. That is just a fact of software development. These flaws occur because the way a piece of software is written is a reflection of what the developer’s though processes are and what challenges he or she is trying to solve. Because human thoughts are not logically perfect all of the time, errors will occur. Also, software development is always a trade-off between time/money and features leading to items left partially coded or rushed through. Which leads us to the next lesson…
Lesson 2. Check-in often.
Everyone is using source control, right? If you are not, start now! When developing software or doing heavy refactoring, source control is your friend. The more often you check-in a usable piece of code the easier it is to rollback if you completely screw something up. On teams that require a code review before check-in or they freeze check-ins setup a private source control server it is so quick and easy. I always think of source control as an undo button and it partially frees the developer from the fear of screwing up publicly. If you use source control and unit-tests almost all fear just goes away.
Lesson 3. Tests, gotta love them.
Ahh unit tests… Everyone says you have to use them and they are the best thing since sliced bread. I happen to agree for the most part. When doing greenfield development I make sure unit tests are always written and used. However the idea of unit tests as a part of the normal development cycle has only become semi-common in the last five years and good software was built long before then. Keeping a list of common tests that should be ran outside of an IDE is also a great thing to have. I think the greatest advantage of unit tests is that as long as they are quick to run it allows for a quick sanity check for the developer. If source control is the development undo button then unit-tests are the babysitter that yells at you for doing something you wouldn’t do if your parents were around.
Lesson 4. Refactor, check-in and repeat.
No piece of code is perfect but it can hopefully become better (and yes it could get worse) by going back over and asking the questions “what can I do to make this shorter, easier to understand, etc…” People do this all the time when writing papers but it doesn’t happen often when writing code. After each interval, check-in the code in case you go too far and removed some needed piece of code. Depending on the size of code being refactored there might be many iterations.
Lesson 5. Coding is easy, humans are tough.
Don’t get me wrong, there are some hard problems in coding but they are not as hard as figuring out what our fellow beings want out of a piece of software. Humans tend to be fickle and contradict what they say. On top of that it is very hard to communicate clearly and a barrier exists between “geek-speak” and normal vocabulary. It becomes extremely difficult to figure out what users are asking for.
Lesson 6. The more eyes on your code the better.
Whenever I go into a new code base or one I haven’t been into for a few weeks I always spend a few minutes browsing around looking for things to improve. When I spot something that was a bad implementation or just a bug I shoot an email over to the developer and let them know how it could be improved (I also change the implementation to make it better). I ask for and expect the same thing out of any developer I work with. Why? Because it keeps us honest and teaches us ways to make our programs better. Sure, this might not be a sit-down code review but I find this to work fairly well at least for smaller teams. The more formal code reviews are nice to and have similar goals: higher quality code, bugs found before QA gets it and information transfer. I think it all depends on the environment you are in.
Lesson 7. Keep learning and improving.
This lesson is pretty obvious but it has to be said. If you don’t learn and/or keep improving you risk becoming a fez which I doubt anyone wants. My usual metric is:
- 1) What new language / technology / technique did I learn in the past month?
- 2) When looking at my old code can I easily find better ways to do things?
I think the second metric is very important. If you can’t think of ways to improve the code – even if it is not feasible in the current code base – then you should be concerned as that is one sign you are not growing.
Lesson 8. Simple is beautiful.
The acronym KISS is awesome and I try to follow that when developing software since I also believe in the idea that as software grows it becomes more complex. Whenever I have to fix an issue or write code I always ask myself “can it be any simpler?” Simplicity has many benefits and not just from a development perspective some of them are:
- Code is easier to understand
- Maintenance tends to be easier
- Simple UIs tend to make programs easier to use
Lesson 9. Learn software development not coding.
Personally I make a distinction between coding and actual software development. I think there are far too many people who focus on just the coding portion and not the bigger picture. Many people can write code but it seems fewer people can design a system, test a system, write the code, document the architecture, talk to users to figure out requirements, create semi-accurate estimates, help other team members and when designing a user interface know the basics of user interaction. There are things all developers should know about coding as well but I feel improving your coding chops is pretty easy and is done as you develop software. Learning and improving in regards to software development is not necessary for one to hold done a job as a programmer.
Lesson 10. Think about your audience.
When reading this point did you immediately jump to the users of the program for which it is being created? If you did you forgot a few other audiences :). Whenever you code I find that there are at least 4 audiences: the compiler, other programmers / your future self, attackers/malicious users and then the users of the program. All of these audiences require different things and the easiest audience to please is the compiler. The other audiences take a bit more work while creating software. For example the attacker audience we really want to piss off instead of please and pissing off an attacker is fairly easy by just not trusting input and properly encoding output (note: this won’t protect you from everything in the attacker arsenal but it will take care of a huge amount). The developer audience is fairly tough as we tend to think all other code is stupid or at least have an opinion about it, this stems from the differences in how each person thinks (at least that is my opinion on it). Commenting business logic, writing clean and clear code and keeping it simple usually helps the development audience. For the actual users of the program they are an interesting group. There are many books on usability and design so I am just going to suggest you pick-up a few good books on that matter (if you need any suggestions feel free to get in touch with me).