Summary
In this chapter we’ve covered requirements, design, implementation, testing, and documentation. It should be obvious now why a software project without requirements is a like a ship without a rudder. Without at least some basic requirements, it’s all too easy to create something that doesn’t do what was originally intended, or doesn’t work correctly at all. We have also seen how testing, when done to the requirements, not only helps to identify defects in the code, but also helps to ensure that the code stays on track and meets the requirements. Writing, in the form of documentation, has been stressed throughout the discussion, and in all honesty, if you aspire to achieve recognition for your work you need to document it so that others (who may not have your depth of understanding) can readily understand and appreciate it. However, the main point in this chapter isn’t about rigorous adherence to a particular process or life-cycle model, nor is it about creating massive tomes of technical details. It’s about knowing where you want to go by knowing what you need to do in order to get there, knowing when you’ve arrived, and creating a map of your journey in the form of documentation so that others can follow the path.
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access