My General Rules of Software Engineering

1
My General Rules of Software Engineering

• David Steffy

2
Introduction

• David Steffy
• BS Computer Engineering, Virginia Tech
• MS Computer Engineering, NC State
• 9 yrs at Nortel Networks software validation,
  software development management
• 7 yrs at Intel software development management
• Currently, managing a team of engineers
  developing 3D graphics drivers to enable Intels
  embedded 3D graphics hardware.
• Very strong believer in software engineering.

3
Have a process, and stick to it

• A process is not a burden, it is a tool that
  helps you.If your process is a burden, its not
  the right process.
• You dont make money on your process, but your
  process helps you make money.
• Think of building software like building a house.
  Start with requirements, create blueprints,
  then break out the materials and tools.

4
Document document document

• Words are cheaper and easier to write than code.
• Writing things down forces questions to arise.
• You have something to share with others.
• You have something to jog your memory. (You
  will forget something, I promise.)

5
Know your requirements

• Everything goes back to the requirements.
• Get them in writing. Get them prioritized.
• Respond to them in writing.
• This forms the basis of a contract (formal or
  informal).
• All subsequent steps refer back to the
  requirements.
• Non-customer-driven requirements
• Choice of languages and tools
• Testability and debuggability
• Regulatory
• Implied?
• Others?
• Requirements will change. They always do.

6
Design pays for itself

• Dont be in a hurry to start coding. Design
  first.
• Up-front design pays for itself, usually more.
• Drive refinements to the requirements early.
• Anticipate dependencies early and accommodate
  them.
• Words are cheaper and easier to rewrite than
  code.
• Design reviews are far more valuable than code
  reviews.
• Coding is more fun if youve designed up front.
  Honest.
• Your schedules will be more accurate.
• Remember testability, maintainability,
  extensibility.Be prepared for the requirements
  to change.

The happiest, most successful developers I have
managed did up-front design.
7
Scheduling

• Software developers are horribly optimistic
  schedulers.
• Schedules without design are worthless. Give
  time for design before you demand or deliver
  schedules.
• Granularity in 1-week deliverables, preferably in
  days. If you cant do this, then your design
  isnt detailed enough.
• Keep track of schedule dates
• Planned your first commitment, it doesnt
  change.
• Forecast your current commitment, it changes if
  needed.
• Actual what you actually achieved.
• History the best predictor. Learn from past
  projects.
• Padding isnt sneaky its practical.

Those who invested in design were far more likely
to meet their schedules.
8
Coding

• Source control is a must.
• The best coding standard is consistency. Beyond
  that, avoid religious wars.
• Code for maintainability. Keep it clear and
  obvious.
• Comments are good, but the best code is
  self-documenting.
• Code for testability.
• Build in ULT interfaces and debug mechanisms.
• Create test programs and utilities as you go.
• Code for extensibility
• Anticipate new features leave room to grow.

9
Validation/Quality

• Allocate sufficient time/resources to validation.
• Track defects (pre- and post-release). Use this
  information to make decisions.
• Validate against the requirements.
• Stability is critical
• Self control
• Source control
• For every two bug fixes, a new bug is created.
• Beware the one line change!Even one character
  in C is powerful.