Building (good) Software
It is not easyI learned from my first job at OTI that building good software is not easy. It requires a large amount of self discipline. Developers must concern themselves with quality at every stage of development. Developers must constantly be asking themselves questions:
Beginning and advanced developers all ask themselves these questions. It is the emphasis that changes. While beginners are often concerned about making the system as general and reusable as possible, advanced developers are far more often interested in how simple they can make it and still get the functionality and performance required. Beginners often assume their code works. Advanced developers are afraid their code doesn't work. They constantly try to break it. As Joseph King says "Listen to that little voice in the back of your head". Techniques I have learned for Writing Good CodeSteve McConnell in "Code Complete" tells us what good code looks like and how to do it. For example, you want to write intent revealing code that uses real world terminology. However, you need to be really smart to do some of these things. Unfortunately, I'm not really smart. Here are some tricks and techniques that I have learned to write better code. Have a version management tool.You cannot live without one of these. CVS is easy to use and free. Now you have no excuses. Write your tests first.This is a real eye opener. ClearStream taught me how to do this properly. It is the most important technique I have learned in my career. It has a wealth of benefits including:
Refactor your code constantly and mercilessly.You know you didn't get it right the first time. When you see it again, fix it. Rename those methods and variables so that you can understand their meaning right away. If you can't understand what you wrote how can anyone else? Fix your bad design or architecture as soon as you can. If you don't who will? The tests that you wrote will tell you if you break anything. You will need to be using some of the advanced tools such as eclipse or the IntelliJ IDEA environment to be able to effectively do this. Read the introduction to Martin Fowlers book "Refactoring". Communicate. Communicate. Communicate.Other people know more than you in different areas. Ask how they solved a problem, talk about the solution that you have come up with. Discuss the problem you are solving. Talk about changes to the architecture. You will learn, your code will be better. Try writing your methods in reverse.If you write your methods (from the return statement up) you get intent revealing code. Fewer variables that look like "flag". I personally only use this occasionally, when methods seem complex. Code Review can be funPair programming makes code reviewing fun, and much more effective. Most of us have trouble staying awake during a detailed code review. You're looking at stuff that is already complete. Anything you say will be criticism. If it requires a large change, you're hesitant to say anything. Pair programming turns code review from work into fun. You are actively working on a problem with a friend. You are discussing, rather than critiquing the solution. It also turns out that there are two different roles when you are pair programming. The person at the keyboard is often immersed in the syntax and the immediate problem, the other considers the intent of what you are doing and how it fits in with the rest of the code. Surprisingly, it appears to be faster than two people coding separately. Tools won't solve any problemsTools don't really solve any problems, they help you solve problems. Don't expect them to be saviours, use them when they help you solve a problem. Good Code does not make a Good ProductAt RightsMarket I learned that good code does not guarantee a good product. Does anyone want what your building? Are you building a solution in search of a problem? At TeamWave (now part of Sonexis) we built a technology in search of a solution. It was intended to be a technology play but we ended up in the wrong playground - community software. It was painful to discover. We recognized it and moved on. Our CEO (Fred Yee) was not naive and we spent time figuring out a more appropriate problem to solve. We moved into web conferencing, where the software was immediately popular. The company sold mere weeks after the software was completed. It is important to remember your job is more than writing good code. Are you writing a good product? Let process help youMany development teams are afraid of process. In some cases rightly so. In other cases not so. Do not let your fear of any process prevent you from using any process. You probably already have some. Identify it. Play with different processes. A process is simply a tool. As a developer you need many tools in your toolbox. Not everything is a nail. At times you will need to do upfront architecture and design. Other times you will need to do almost none and you can use agile techniques like extreme programming. Use combinations of both. At TeamWave we found that design could often be done on the fly and developers could sit at their desk and come up with a fairly simple design quickly and implement it. Other pieces were more complex and required a Design Note which allowed the team member to clearly think through the problem and then discuss their ideas with the team. Examine what you do. Try changing what you do. See if you get better. How do you get a high performance team?Working on a high performance team is the best thing in the world. You churn out high quality software that people want at an amazing rate. OTI is a stellar example of that. Over 100 developers churning out the Smalltalk and Java for IBM Visual Age products. Now they are producing eclipse. These people are phenomenal. How do you get to be like that? The formula is magic. I don't know what makes the magic. However I have noticed many commonalities in High Performance teams that I have worked on:
|
|