Coding to Spec

eading "Dreaming in Code" at the moment. The book portrays programmers as extremely literal and needing to work off detailed specifications.

That has not been my experience at all. When I receive a specification I treat it as a starting point.

• I go through the UI design and alter it to make it more consistent both internally and with any pre-existing parts of the program. User experience is improved by predictability and simplicity.
• I look for common anti-patterns like 20 question syndrome.
• I start asking questions.
• Is the requested functionality already in program? Was it originally in the program but then removed because of negative customer feedback? Is part of the functionality already in the program if so can this be re-used in a natural way?
• If the program is asking the user to make a decision is the information needed to make the decision visible at that point in the program or does the user need flip through several screens to get what they need?
• Is the program asking the user make a decision that they should not be making? It is amazing how often software will throw up a dialog with Yes/No button when it is unrealistic to expect the user to make an informed decision. 
• "Error 1234. Press Okay to continue" 
• "Foo is changing something important. Do you wish to continue Yes/No"
• How easy to undo a decision? People make mistakes. People are also more productive when they can explore different options. Filling the program with "Are you sure Yes/No" messages is not an adequate solution. People become conditioned to hit the "Yes" button automatically without thinking. The brain is every good at filtering out noise.
• Are the terms in the specification ambiguous or have different meanings to different groups?. e.g 
• in the pharmacy industry depending on the context a generic can be either a "set of active ingredients" or a "non-premium brand of drug"
• preferred suppliers are actually manufacturers and not suppliers.
• Does program work with or against the natural workflow of the task?
• Are there non-functional requirements? e.g. security or response time.

After I have gone through some preliminary analysis I will have some hooks to start conversions with the various stakeholders in order to fill in some of  the details missing from the "complete" specification. Taking time to go beyond superficial understanding of the people involved pays great dividends and there are always more stakeholders involved than you first think. After this it is time to start talking to the business about trade offs, options and consequences that they probably have not thought of.

• simplicity, predictability and consistency versus adapting program behavior to context.
• ease of use versus power and flexibility.

I do not always follow this process but when I do I have far better results and when I do not I usually regret it.

If your programmers are complaining about incomplete specifications perhaps you should ask your team some questions.

• Do you have a blame culture? If everyone is busy diverting blame for problems away from themselves no-one is busy finding solutions to those problems.
• Is there to much time pressure? If programmers start asking more questions they are going to get more requirements, which are going to take more time to implement.
• Have you got the right programmers?

I have never seen a complete specification for any project that was not trivial and yet the specification and the project takes life and substance as I communicate with the stakeholders and craft and design code.

Software Development Book List

hen I started developing software my focus was on technology, programming languages and tools. Therefore my reading reflected this. However as I progressed I found less and less of the problems I was running into were technical in nature and therefore the material I started reading changed. This was because the most difficult problems in software development are often not technical in nature but involve communication, process, organizational and people problems. 

I never stopped reading technical material, however this information’s usefulness is very contextual. You are not going to need a book on the C++ boost library if your project is implemented in Javascript for instance. I began to take a more targeted, just in time approach to technical information. There are many articles, books and resources however that are more broadly applicable and are worth proactively studying.

Here is my top ten must read books for anyone serious about software development.

The Mythical Man-Month: Essays on Software Engineering, (2nd Ed) by Frederick Brooks 

Those who are blind to history are doomed to repeat it. This timeless classic helps you navigate around certain problems that crop up once your project reaches significant size and complexity. Technologies may change but dealing with people inside and outside the team, unknowns inherent in doing something new, and complexity involved capturing value beyond the obvious low hanging fruit, that hasn’t changed.

The Design Of Everyday Things by Donald A Norman

Everyone who has struggled with a piece of technology that does not work as they expected it to understands the value of good design. I have talked about this in more detail elsewhere. It is unfortunate that some developers blame users of their software for misunderstandings. The problems are usually not with the users but with the design of their software.

The Fifth Discipline : The Art n Practice of The Learning Organization  by Peter Senge

It is tempting when embarking on a software project to rush into implementing the first solution proposed. However it is better to take the time to understand the problem domain and to understand the system the eventual solution needs to be a part of. The Fifth Discipline teaches a system thinking approach that can save your project from going down a blind alley.

 To Yes - Negotiating Agreement Without Giving In by Roger Fisher and William Ury

Sometimes you do not have the authority to remove road blocks that are crippling your project, especially if third parties are involved. It this case you need persuasion, influence and negotiation.

The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen

Whether is it the work involved in implementing your project, or the business processes interacting with or embedded within your problem domain, or the workflow and processes that your implementation encourages users to follow, concepts such as scheduling, workflow and queues are everywhere. This book will help you manage that flow. To quote the book -

“What actually works is surprisingly different from the standard advice.” 

Reinertsen's advice is non-standard, systematic, very detailed and very good.

Patterns : Elements of Reusable Object-Oriented Software by GoF (also known as Eric Gamma, Richard Helm, Ralph Johnson and John Vlissides )

Shows a way of capturing proven reusable solutions for commonly occurring problems, solutions that have been reinvented over and over again by different software teams in different industries using different technologies. For many years my teams would study a different design pattern each week during the weekly brown bag lunches.

Refactoring : Improving the Design of Existing Code by Martin Fowler

Allows you to safely keep your code flexible and easily modifiable.





Fearless Change : patterns for introducing new ideas by Mary Lynn Mann and Linda Rising 

As a software developer you are automatically an agent of change (If you are successful that is. If your software doesn’t change anything that's a different problem). This book helps you introduce change into your organization.

Retrospectives : Making Good Teams Great by Esther Derby and Diana Larsen

If you don’t reflect on your experiences you are unlikely to improve. This book gives you the tools to systematically and regularly assess those experiences.



Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries

A startup environment has many differences from an established company. Startups are often in a customer search phase rather than a product development. This will impact how you approach software development in each environment.  

The following books are close runners up to the top 10.

Working Effectively with Legacy Code by Michael Feathers

Not everyone has the luxury of working in a greenfield environment. It can be difficult to make changes to an established application that has no unit test without introducing breaking changes. This book gives you strategies to make changes safely.

Quality Software Management volumes 1, 2, 3, 4: by Jerry Weinberg

A smorgasbord of useful advice distilled from a long consulting career.

Kanban by David J. Anderson

Limit work in progress and reduce cycle times.

Agile And Iterative Development : A Manager's Guide by Craig Larman

Compares and contrasts many light-weight processes and gives evidence that they produce better results than heavy-weight processes. 

Refactoring to Patterns by Joshua Kerievsk

Either introduce and remove patterns to your code without breaking anything.

 The Five Dysfunctions Of A Team : A leadership fable by Patrick Lencioni

Trust is the key. If your team is not working effectively together, then the chances of successfully completing your software project is greatly reduced.

Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James P Womack and Daniel T Jones

Explains many of the core concepts of lean. 

Out Of The Crisis by William Edwards Deming

How to manage variation. What is significant incident and what is random noise. How to improve practises and processes in a systematic way. The original source of many lean concepts.

Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck plus it's sequels

Applying lean thinking to the software industry.

Collaboration Explained: Facilitation Skills for Software Project Leaders by Jean Tabaka

Gives techniques for promoting collaboration and coordination.

The Goal: A Process of Ongoing Improvement by Eliyahu M Goldratt 

Uses narrative to explain flow and the effect of queues on systems. Less systematic than The Principles of Product Development Flow. Gives some theory behind the recommended practices but lacks the comprehensive theoretical framework contained in the other book.

The Effective Executive by Peter F Drucker

It is all about priorities and making sure your behaviour matches your stated priorities.

Influence : Science and Practice by Robert Cialdini

Sometimes you do not have the needed authority to achieve your objectives. As I said before you often need persuasion, influence and negotiation. 

The Toyota Way : 14 Management Principles from the World's Greatest Manufacturer by Jeffrey Liker

Explains many of the core concepts of lean.

The World Is Flat : A Brief History of the Globalized World in the 21st Century by Thomas Friedman

Some times in software development you need to interact with third parties. This book opened my eyes to alternative ways companies and organizations can coordinate with each other. Giving examples where these methods have been effective.

 

Updated 31 Dec 2015