05 March 2008

My Top Software Development Practices

There are many great books on software engineering many of which give a lot of great advice. There are probably 100+ excellent software engineering books that between them give 1000+ tips on developing software. The challenge for practicing software engineers is to know which practices to start with. This post about Google's engineering practices showed Google's top 12 development practices. Here are my top 10.

My Top 10 Development Practices

  1. Assemble the best team you can afford and keep them.
  2. Fit the solution to the problem.
  3. Be data driven. Measure progress with tests. Keep a diary with 1 day to 1 week granularity.
  4. Expect the unexpected. Maintain a Top 10 risk list . Confront risk by moving the riskiest items to the start of the schedule.
  5. Work in short development cycles with real-world success criteria. If you don't then your project and its schedule are at risk of losing touch with reality.
  6. Use the product you are developing.
  7. When you have enough information to act then act. Time is precious in software development. Never waste it.
  8. Have a common tool set and common practices for the whole development group and make these tools easy to deploy. Aim for near-zero (say 5 minutes) tool setup time per day.
  9. Use source code control!
  10. Be balanced. Don't rely on any one software engineering practice. e.g for quality control use Code review + Unit tests + Automated System tests + Human QA. .
Supporting Quotations
  1. .
  2. .
  3. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. - Sherlock Holmes
  4. Whatever can go wrong, will go wrong. - Murphy's Law
  5. What Descartes did was a good step. You have added much several ways, and especially in taking the colours of thin plates into philosophical consideration. If I have seen a little further it is by standing on the shoulders of Giants. - Isaac Newton
  6. … the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. … If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important. - Donald E. Knuth
  7. Delay is the deadliest form of denial. - C. Northcote Parkinson
  8. I believe that the average farmer puts to a really useful purpose only about 5%. of the energy he expends.... Not only is everything done by hand, but seldom is a thought given to a logical arrangement. A farmer doing his chores will walk up and down a rickety ladder a dozen times. He will carry water for years instead of putting in a few lengths of pipe. His whole idea, when there is extra work to do, is to hire extra men. He thinks of putting money into improvements as an expense.... It is waste motion— waste effort— that makes farm prices high and profits low. -Henry Ford (1922, My Life and Work)
  9. .
  10. .

5 comments:

Peter Williams said...

See also
http://blogs.construx.com/forums/p/787/1744.aspx#1744

Peter Williams said...

Re: Principles and Practices of Software development
By Earl Beede in Management

Peter,
That sounds close to the eight software engineering principle we talk about in out 10x Software Engineering class.
Avoid minus-x engineering (classic mistakes)
Seek ground truth
Base decisions on data
Minimize unintentional rework
Tailor the solution to the problem
Attack uncertainty
Set direction
Grow capability

Anonymous said...

I'm unsure about the importance
of #8. Often different engineers have different tools and style that
can be complimentary. It's important to be able to give a new engineer
a development image that can get him up and running quickly, but I
think it's important for engineers to explore new tools without feeling constrained.
-Truxton

Peter Williams said...

See also
http://www.noop.nl/2008/07/the-definitive-list-of-software-development-methodologies.html

Paul said...

6. Use the product you are developing.

Ford has this policy
http://en.wikipedia.org/wiki/Dogfooding . Maybe the cars were even worse before they started doing this.

Of more concern, Microsoft appear to have introduced this idea to software development, which indicates that while this might be a necessary condition for good development, it is not a sufficient one.