Standing on the Shoulders of Giants - Billy McCafferty

Standing on the Shoulders of Giants

Needlessto say, computer science is still in its infancy but has madeincredible strides in just over half a century.  During this time, it'sstriven to get the respect it deserves as a disciplined subject.  Evenjust 14 years ago, when I started my undergrad in this subject, Irecall reading articles debating whether it should be called a scienceat all.  Gladly, I do not see this argument thrown around muchanymore.  From Knuth's classic work in The Art of Computer Programmingto the wide-spread use of pure mathematics in describing algorithmicapproaches, computer science has the proper foundations to join otherrespected sciences such as physics, concrete mathematics, andengineering.  Like other sciences, computer science demands of itsparticipants a high level of respect and pursuit of knowledge.  But,unlike other sciences, it is difficult to enforce that its participantsgive it the level of respect it deserves nor pursue it with the samelevel of discipline that other sciences require.  Consequently, thescience behind software development is often neglected or not takeninto consideration whatsoever.  This becomes reflected in thewidespread impressions that software is fragile, that accurateestimating is impossible, and that managing software development islargely undisciplined.

To improve impressions of mainstream software development - which,presumably, should be based upon the foundations of computer science- it comes upon the shoulders of each developer to educate him orherself with the knowledge necessary to give this discipline properattention.  Developers cannot push off this responsibility tomanagement or "the priority setters."  It is up to each of us to givesoftware development the respect it deserves and educate those aroundus, accordingly.  Helping to assist this cause does not require amasters degree in computer science, or even an undergrad degree(although I recommend it), but it does require a commitment to learnfrom the mistakes of experts that have come before us so as not torepeat those mistakes again.  A former professor of mine, wiser than I,said that you will not be an expert in computer science until you havemade every mistake possible.  Fortunately, we need not make all ofthese mistakes ourselves as many have come before us to pave the wayand leave behind the lessons they have learned.

Although there is no single best practice, practices doexist which embody the lessons learned from years of painfulexperiences and hard won insight.  This is not to say that allthe practices described are not subject to critique and improvement,but they do serve as a confident starting point for engaging in our owndaily practice.  Ignoring them outright, which is almost a norm withinthe world of software development, is an injustice to the science inwhich we say we engage ourselves.  Structural engineers do not startdesigning a building's structure without first investing a large amountof time understanding engineering best practices garnered fromcenturies of engineering practices that have come before. Unfortunately for them, if they do not do this, lives may be at stake. Unfortunately for us, we do not usually have such pressures to committhe same level of care and attention to our own work.  Furthermore, itis frequent that management does not support the time required forlearning and executing ideal software development practices.  Both ofthese disadvantages to software development can almost always beovercome by empowering software developers with the adequate educationfor implementing proper practices and methodologies.  Fortunately forus as developers, this empowerment is in our own hands.

In a sense, this message is a call to arms for software developersto give our science the respect it deserves as expressed in our day today work.  We are engaged in a practice which the world is becomingmore and more dependent upon; in all seriousness, there are few othersciences which will have as big an impact on the world in the comingcentury as computer science.  The first step that each of us can taketo better the integrity of our science and assist with its advancementis to pick up a book.  Although not all are equal, key texts infuse inus the wisdom of many years of development and the expert knowledgegarnered from many mistakes.  What follows is a minimal course ofreading for infusing such knowledge, becoming a better softwaredeveloper, and giving computer science proper respect in your dailypractice.  I suggest that they be read, believed, and implemented inyour daily practice.  Works by authors such as Martin Fowler are notjust books full of ideas that he invented, they are tried and truepractices built upon the shoulders of giants which can serve as aplatform for standing on the giants' shoulders, ourselves.

Foundational Texts

What follows are key texts that every OOP developer should read,without exception, regardless of experience or platform.  The order ofthe list is the order that I suggest reading them.  These texts focusmainly on writing better, maintainable code with a transition to solidobject oriented design.

• Code Complete, 2nd Ed. by Steve McConnell
• Refactoring by Martin Fowler
• Refactoring Workbook by William Wake
• Applying UML and Patterns, 3rd Ed. by Craig Larman along with a companion text of UML Distilled, 3rd Ed. by Martin Fowler
• Object-Oriented Design Heuristics by Arthur Riel

Apprenticeship Texts

These texts help one move from focusing on the code to seeing theimplementation from a higher viewpoint and improving the integrity ofthe project as a whole.

• The Pragmatic Programmer by Andrew Hunt
• Patterns of Enterprise Application Architecture by Martin Fowler
• Test-Driven Development by Kent Beck
• Refactoring to Patterns by Joshua Kerievsky
• Head First Design Patterns by the Freemans and a companion text of the gang of four's classic work, Design Patterns, for post-read reference

Journeyman Texts

These texts move towards more "putting it all together," wranglingthe software development process, and getting into the "science" behindcomputer science.

• The Mythical Man-Month by Frederick Brooks
• User Stories Applied by Mike Cohn
• Agile Software Development or Agile Principles, Patterns, and Practices in C# by Robert Martin
• Applying Domain-Driven Design and Patterns by Jimmy Nilsson
• Rapid Development by Steve McConnell
• Extreme Programming Explained, 2nd Ed. by Kent Beck and/or Agile Project Management with Scrum by Ken Schwaber
• Introduction to Algorithms by Thomas Cormen

The Beginnings of Mastery

These texts help hone your skills along with improving the efficiency and effectiveness of your team.

• Domain Driven Design by Eric Evans
• Working Effectively with Legacy Code by Michael Feathers
• Agile Estimating and Planning by Mike Cohn
• Lean Software Development by Poppendiecks and their companion text, Implementing Lean Software Development

Mastery Texts

Although not to be seen as compulsory as the above texts, whatfollows will assist in taking you into the realm of pure computerscience.  At the very least, they serve to demonstrate that our workhas solid foundations in quantitative science.

• The Art of Computer Programming, Volume 1: Fundamental Algorithms, 3rd Ed. by Donald Knuth along with volumes 2, 3, 4 (and its derivative works)
• Concrete Mathematics: A Foundation for Computer Science, 2nd Ed. also by Donal Knuth

With the above listing, I've attempted to de-emphasize emerging techniques, such as Software Factories or Product Lines, infavor of established better practices for improving the design,development, and management of software development for yourself andorganization.  Obviously, taking on these texts cannot be done in aweekend and requires years of trial and error in implementing thetechniques implied.  But I assure you that embracing the ideasdiscussed will dramatically improve you as a software developer andhelp move your practices closer to the realm of disciplined computerscience.

Billy McCafferty