Some Basic Rules of Development
I've been developing software by myself for the better part of 20 years now, and in a team environment for at least the last 6 years. Here are some of the lessons I've learned along the way. Not all of these are 100% my own ideas, but I can state that I've "taken ownership" of all of them, having been both a developer and a development department manager:
1) A development team should have a single design authority. The best systems have one member of a team who dominates the design and development and has a clear view of where the system is going. Without this strong focus and lead, many projects throw together a set of conflicting ideas and the system will ultimately stagnate or become extremely difficult to maintain. This person needs to be big on communication and small on ego.
2) Code should be documented, but not overdocumented. Lots of documentation does not equal good design and will not guarantee a good, well designed system. A system can have a good design even with minimal documentation. Especially, keep in mind that the initial set of documentation is for the DEVELOPERS THEMSELVES.
3) Good people build good systems, bad people build bad systems. No amount of processes or documentation will change that, it will only make a relatively small increment in system quality. The overwhelming factor in developing a quality solution is to hire good people. NASA statistics have shown productivity differences of 1000% between their best and worst people.
4) Design for change and flexibility. Things will always change, do not tie your system to rigid principles or business processes that change frequently. Break your system up into its OOP oriented objects and define them as early as possible in the development cycle. Make sure everybody on the team understands what the objects are and what their purpose is, and how they will interact with each other.
5) Don't build a foundation on a sand dune. The first few steps in the project are usually the most critical: the choice of tool, platform, architecture etc. If the wrong choices are made, it can result in a lot of rework and will destroy the motivation of most development teams. If you find early in your process that a decision may have been wrong, be smart enough to change it instead of attempting to "Band-Aid" it into functionality.
6) Keep it simple, don't build in complexity that doesn't need to be there. Don't spend time making the system portable if it doesn't need to be. If you're using SQL 2005 and are going to stick with it, use all the SQL 2005 specific features you like. "Explicit code is easier to understand, which makes the code easier to modify" -- Martin Fowler
7) Use accepted and well-known technology. Niche tools/technologies are expensive, lack support and it can be difficult finding people with the right skills, particularly a couple of years later.
8) Deliver often. A project taking more than 6 months before delivering software will likely fail and the reasons for it being built may not even apply anymore. Delivering often provides good targets for developers and good visibility for the system in question. If you have 3 Alphas and 6 Betas over a short period of time, that's better than no Alphas and one Beta. User feedback is extremely important in being able to be flexible enough to make mid-course corrections.
9) Don't add extra people to a team to try and speed up development. Increasing the size of a team mid project will almost certainly slow development down. A team of 4 to 6 developers is enough for most projects. Large projects should be broken down into small development teams of this size.
10) Use industry-accepted development methods: object-oriented design and modelling, well-structured development process, unit testing, sound documentation, use of version control tools, project management tools.
11) Communicate often within the team. You don't need four different people each creating their own Data Accesss helper class when if they had all sat down and discussed it first, everybody could all be using the same one, with better features.
12) Above all, do be nice to your development team. Developer turnover in the middle of a project can really send expenses through the roof, and morale down the toilet.
1) A development team should have a single design authority. The best systems have one member of a team who dominates the design and development and has a clear view of where the system is going. Without this strong focus and lead, many projects throw together a set of conflicting ideas and the system will ultimately stagnate or become extremely difficult to maintain. This person needs to be big on communication and small on ego.
2) Code should be documented, but not overdocumented. Lots of documentation does not equal good design and will not guarantee a good, well designed system. A system can have a good design even with minimal documentation. Especially, keep in mind that the initial set of documentation is for the DEVELOPERS THEMSELVES.
3) Good people build good systems, bad people build bad systems. No amount of processes or documentation will change that, it will only make a relatively small increment in system quality. The overwhelming factor in developing a quality solution is to hire good people. NASA statistics have shown productivity differences of 1000% between their best and worst people.
4) Design for change and flexibility. Things will always change, do not tie your system to rigid principles or business processes that change frequently. Break your system up into its OOP oriented objects and define them as early as possible in the development cycle. Make sure everybody on the team understands what the objects are and what their purpose is, and how they will interact with each other.
5) Don't build a foundation on a sand dune. The first few steps in the project are usually the most critical: the choice of tool, platform, architecture etc. If the wrong choices are made, it can result in a lot of rework and will destroy the motivation of most development teams. If you find early in your process that a decision may have been wrong, be smart enough to change it instead of attempting to "Band-Aid" it into functionality.
6) Keep it simple, don't build in complexity that doesn't need to be there. Don't spend time making the system portable if it doesn't need to be. If you're using SQL 2005 and are going to stick with it, use all the SQL 2005 specific features you like. "Explicit code is easier to understand, which makes the code easier to modify" -- Martin Fowler
7) Use accepted and well-known technology. Niche tools/technologies are expensive, lack support and it can be difficult finding people with the right skills, particularly a couple of years later.
8) Deliver often. A project taking more than 6 months before delivering software will likely fail and the reasons for it being built may not even apply anymore. Delivering often provides good targets for developers and good visibility for the system in question. If you have 3 Alphas and 6 Betas over a short period of time, that's better than no Alphas and one Beta. User feedback is extremely important in being able to be flexible enough to make mid-course corrections.
9) Don't add extra people to a team to try and speed up development. Increasing the size of a team mid project will almost certainly slow development down. A team of 4 to 6 developers is enough for most projects. Large projects should be broken down into small development teams of this size.
10) Use industry-accepted development methods: object-oriented design and modelling, well-structured development process, unit testing, sound documentation, use of version control tools, project management tools.
11) Communicate often within the team. You don't need four different people each creating their own Data Accesss helper class when if they had all sat down and discussed it first, everybody could all be using the same one, with better features.
12) Above all, do be nice to your development team. Developer turnover in the middle of a project can really send expenses through the roof, and morale down the toilet.
Wouldn't having an individual dominate the design and development produce an increased risk of having "a foundation on a sand dune". The design would be limited to the creativity of a single person. The development is based on the knowledge of a single person. If this person is not small on the ego then there would surely be increased turnover. Could the risk of having an ego in that position be eliminated by having the design and development collaborated as oppose to dominated.
ReplyDeleteI totally agree with Trystan. Having worked on projects where the design was dominated by one or two people, I know the pitfalls this can cause. I do think that the final design decisions should be made by one or two people, but without any collaboration on design you losing out on the collective knowledge of the development team. I've found that people, especially developers, don't like being told what to do and have their creativity stonewalled, and having one person, small or large ego, dominating the design, usually ends up with lower morale and less developer ownership of the project.
ReplyDeleteA ship without a rudder and a Captain goes nowhere. Sure, there are "bad captains", your point is well taken, but Bad Captains can be replaced.
ReplyDelete