In order to write good software you need some sort of process. As it turns out it doesn't really matter much which process you choose but there are a few key elements to a good process.
1) It must focus on your customer.
The first thing to get right is to solve the problem that is most needed by your customer. This can be a bit hard to determine because in most cases the customer will tell you what they think you can solve rather than what you can solve.
This means that sometimes they want you to do the impossible and you need to scale back their expectations or that they have already scaled back their expectations and what they really need to be solved is easy to do.
There is a real art in figuring this out but it is mostly about spending enough time understanding what it is that your customer does. This often means you need to learn something new outside the domain of computer science.
To me the chance to learn something new is the best part.
2) The process must be iterative.
No matter how you end up doing things there needs to be some iteration involved. This has led to many different process methodologies. All the best ones use some sort of iteration.
Basically this recognizes the fact that you can't create a great design without writing some code. Eventually you need to rewrite the code to deal with changes. Sometimes you get it right to start with, but usually that is for a trivial problem that you can already write the code for in your head.
3) The process should be collaborative.
Writing code by yourself is OK, but two heads are better than one. Code that is written by and maintained by multiple people will get better or worse over time depending on the team.
If it is getting worse then you have a problem with your team. Either you or your teammates need to learn to work better together. Almost always it is you that needs to improve. How can that be you ask?
Well what it boils down to is that most software engineers think their code is better than their colleagues. While that may be true in some cases it is almost always true that you can learn something from your teammates about writing better code.
Looking for that and adopting the best of others will make you a better engineer. When you get to this point then it is probably true that your teammates need to improve. They will be a lot more likely to adopt your good habits if you have first adopted theirs.
4) The process must include testing.
This is obvious, but there are some good and bad ways of testing. While you should test your own code it should always be tested by someone else. Testing should be independent and done by a team that doesn't also do development.
The testing team should develop somewhat of an adversarial role with respect to the code. However, it should be more of a friendly rivalry. The goal of the developer is zero bugs. The goal of the tester is to find many bugs.
Failure to achieve either of these should be a sign that the respective team has room to improve.
5) The process should include documentation.
The first documentation should be written by the software engineer. It should be written, no videos, and it should clearly state what the feature should do (requirements) and how it works (specification).
Each of these can be used to produce other documents, a test plan, user documentation, etc.
6) There needs to be accountability.
This can come in many forms. For example source control maintains a record of who did what and when, a bug tracking database records defect and is used to assign them to the appropriate party, a schedule gives management, marketing, and other stakeholders a prediction as to when they can expect delivery so that they can plan accordingly.
7) Return on Investment Must be Estimated.
Technically this goes under accountability, but it is so often ignored that I call it out specifically.
Software that costs more to develop than it saves should never be started. For example if it takes $100,000 to automate a shipping process where the savings is only $20,000 over the next 5 years then there is probably better things to do.
Not only is this a losing proposition, it is likely that the project will get canceled making it an even bigger waste of money and time. It will also piss off the engineers that work on it.
If you are an engineer starting work on a project like this then make sure management knows it is a waste of resources. If they don't listen, move on. You don't need the aggravation, and there are plenty of software development shops around that do work on profitable projects.
On the other hand if adding a feature for $100,000 will add $1,000,000 a year in revenue then it is most likely a good thing to work on.
Spend your development resources where they will make you the most money. It's good business and it's good for the team.
8) Focus on the End Game.
Often from the time of feature completeness to release can take several weeks. Often one thing, such as finishing documentation, web site, marketing materials, etc. can end up taking a surprisingly long time. These needs can often push back the date of feature completeness by a month or two for a given release date.
Gantt charts are very helpful in planning your end game to ensure that everything that has dependencies on the software being complete are done.
9) Use Technology Only When Appropriate.
There are some technologies that are pretty much a given. For example you need a compiler.
Other things should be a given such as using source control and a bug tracking database.
Then there are technologies that may or may not be helpful. Most things can be done manually. Such as managing requirements, specifications, etc. Tools exist to do these things, but are not necessary to write software. Use them only if they really help you.
If they are black holes where information is poured but never used then get rid of them as they are just taking up time.
10) The Process Must be Simple.
If you can't explain it in 10 minutes to your mother and have her understand it, then it's too complicated.
A complicated process will fail. It won't get buy in from your team. It will be interpreted differently by different team members. It can take a long time to be fully adopted.
11) Use Iteration to Improve the Process
With each release you can sit down and examine your process. Figure out what worked well and what didn't work so well. Focus on the areas that didn't work well and figure out how to make them work better.
One thing that happens frequently over time is that as things improve you hit a release where a the quality slips. This tends to come from complacency. You have to keep working to improve.
One way to deal with this is to keep raising the bar. Recognize that you can always improve some part of the process as there is not a perfect process.
12) Adapt Process to Your Needs.
Don't just adopt a process. No process is perfect and every team has slightly different needs.
For example, a young inexperienced team can greatly benefit from pairs programming while a highly seasoned team would only be slowed by pairs programming. Some would argue that point with me, but 30 years of development experience tells me otherwise.
Adapt process ideas to your team needs. Don't just blindly adopt a process as it won't work if you and your team don't understand why you are doing things in a particular way.
Conclusion
With a little effort you can write good software. With a lot more effort you may be able to write slightly better software. But if it doesn't make your company money, it's a bad process.
The traveling salesman problem is a great example of a problem where achieving the perfect solution can take so much compute time that the salesman could have gone with a quick less than optimal solution and be back from his trip before the computation of the perfect solution is finished.
Don't let your process become such a large cost that you can't get the job done.
No comments:
Post a Comment