Conclusions

Engineering is an old field, and no matter whether one is building software, hardware, or railroad bridges, the elements of the engineering process are essentially the same:

• Identify a requirement, and its requirers.
• Design a solution that meets the requirement.
• Modularize the design; plan the implementation.
• Build it; test it; deliver it; support it.

Some fields put greater emphasis on some phases. For example, railroad bridge builders don't usually have to put a lot of thought into an MRD, the implementation process, or support -- but they have to pay very close attention to the SDD and DDD and of course QA. The seminal moment in the conversion of a ``programmer'' into a ``software engineer'' is that instant when they realize that engineering is a field and that they are able to enter that field but that it will require a fundamentally different mindset -- and a lot more work. Open Source developers often succeed for years before the difference between programming and software engineering finally catches up to them, simply because Open Source projects take longer to suffer from the lack of engineering rigor. This chapter has given a very shallow overview of software engineering, and hopefully provided some motivation and context for Open Source programmers to consider entering that field. Remember that the future is always a hybrid of all the best of what has gone into the past and present. Software engineering isn't just for the slide rule and pocket protector set -- it's a rich field with a lot of proven techniques for building high-quality systems, especially high-quality systems that aren't amenable to the ``one smart programmer'' approach common to Open Source projects.