Everyone has their own Top Ten Lists; I like David Letterman’s personally. This one may be a bit specialized, and is definitely for your “inner geek.” Over the years Amadeus Consulting has learned lessons about technology and custom software development that prove invaluable during our engagements. I’ve enumerated some of these below. Yes, the list could be much longer than ten but I could go on about this forever and ten seemed like a reasonable stopping point.
1) DO Define the goal.
There are many schools of thought on the process of software development. Should you go Agile or Waterfall? How about extreme programming or the single cowboy coder? None of these will matter at all if you don’t know what the “win” is. Some call this requirements, some specifications and some call it a pain. It’s really just saying what you’re trying to accomplish. If you don’t define it you’ll never get there.
2) DO Understand the problem.
If you can’t explain the problem to someone else, then you can’t solve it. As custom software developers we write programs for all sorts of businesses and industries that we aren’t familiar with. Over the years we’ve learned that in order to do this successfully we have to be able to explain the problem back to the client in order to solve it.
3) DON’T Abdicate responsibility to the technology.
A hammer is a tool, a screwdriver does not turn the screw; you do. Too often we rely on technology we don’t understand to solve our problems for us. Software development is a smart team of people utilizing the right tool for the job. If your developers start becoming subservient to the tool, SHAKE THINGS UP; have the developers program in another language, do a sprint of nothing but UI. A developer who can’t separate the business problem from the technology is not moving things forward.
4) DON’T Push developers to write when they’re exhausted.
There are things you can do when tired. They include watching TV, playing video games and sleeping. Software application development is hard work. When developers get tired they lose sight of the goal (remember rule number 1) and start churning out code just to get something done. Application development is a science and an art, science requires rigorous thought and energy.
5) DO Use the best tools money can buy.
The best mechanics use the best tools. Picasso didn’t paint with cheap paint. The theme is easy to spot. This business is hard enough without trying to do it with substandard tools. Good developers know this and if you don’t provide them with good equipment the best will go elsewhere. If you stick your developers in the basement with the hand-me-down monitors you’ll get the kind of developers who have to put up with that because they can’t get a better job.
6) DO Break up work into chunks.
I don’t believe in everything the Agile method espouses, but I do think that sprints are excellent. Breaking up a problem into smaller pieces makes it easier to solve. A good development team lead will define smaller goals for each team member and give them something to work on for a day or two at most. Any more time than that and it’s easy to get lost.
7) DON’T Reinvent the wheel.
Or the engine, transmission or anything else for that matter. There are algorithms that work. They’re tested, easy to maintain and probably written by people smarter than you. A big trap is letting developers tinker with things that work. They will probably succeed in getting it to work 10ms faster at the cost of being able to maintain it, use it again and ten million dollars. If the 10ms is worth it, go for it. Developers don’t do this out of malice; it’s a simple matter of perspective. A good manager will give them that perspective and in the end create a team that can do it on their own and be extraordinarily effective.
8) DON’T Reuse code you don’t understand.
This goes back to number 2 in a lot of ways. If you can’t explain a piece of code how can you test or maintain it. The architecture astronauts will bully you and other developers into using a multi-threaded, polymorphic, lamda expression to find the length of a string. This is like building a space shuttle to go down the street and grab milk. Don’t fall for it. Use and write code you, and others, can understand. If it starts going sideways walk away and come back. Unless you work for JPL, there is probably a simpler way.
9) DON’T Ignore the user interface.
Who is the application for? How many people will see the thousands of lines of code you write? I’m not saying to write bad code, or not care about what you’re writing. I’m saying you need to care about the user. If the code is elegant and the user can’t use it you’re worse off than if the code is horrible and the user loves it. At Amadeus Consulting we have a team of graphics and usability experts so that our rock-star developers will always be able to produce something that users will USE.
10) DO Care about the outcome.
I’ve seen many projects succeed or fail based on how much the developers internalize the outcome. If you can’t find some way to connect your developers to the goal, get another team of developers. A developer who doesn’t care about what they’re doing will poison a team. At Amadeus Consulting we know that our client’s success, jobs and sometimes their future are on the line. We take it seriously.
www.amadeusconsulting.com Amadeus Consulting is a custom software development company dedicated to creating intelligent technology solutions. As a Microsoft Gold Certified Partner, we have competencies in Custom Development, Mobility and Data Management. Other areas of expertise include content management, e-commerce, social networking, data collection and management, browser plug-ins, and iPhone application development.
