Re-Defining the Possible

September 8, 2013 — Posted by Scott Bain

Note from Al Shalloway.

This blog was written by Scott Bain, one of our instructors. However, it's a strong statement from all of us. Our combined experience of more than a century and a half bears out Scott's well-crafted message ushering in a new paradigm for design.

Re-Defining the Possible

Scott L. Bain, Net Objectives

For centuries mariners believed there was no way to measure longitude.  Latitude can be determined using a compass, but as there is no east-west polarity on earth it was thought that longitude could not be accurately ascertained. 

Similarly, once the age of flight was upon us many experts said that the speed of sound was the absolute maximum velocity for an aircraft; any attempt to go faster would either negate lift or shatter the vehicle into pieces.

Believing something to be impossible limits your thinking.  After all, if something is truly impossible then why would you spend any time trying to accomplish it?  That would obviously be wasteful.  We would rather focus ourselves on things that can at least theoretically be done. 

Also failure is unpleasant and even frightening at times, so we prefer to aim at goals we have a good chance at achieving.  Aviators who attempted to break the sound barrier experienced severe vibrations in their aircraft as they approached 340.29 m/s, seeming to bolster the theory that Mach 1 meant death.

In the 1720’s a man named John Harrison solved the problem of longitude by re-defining it.  He said that a true-bearing measurement was not needed if one could build a highly accurate clock.  He was right, and once ships began carrying such clocks they no longer lost their way once they lost sight of land.  Countless lives were saved as a result.

Chuck Yeager successfully flew faster than the speed of sound in 1947, and thereafter it become routine to do so.  When the SST was in service it happened every day, with commercial passengers on board.

Our assumptions form a kind passive filter on the way we take in the world around us.  As an analogy, imagine that you were born with a square piece of cardboard mounted in front of your eyes with various shaped and sized holes in it.  If it had always been there you would not notice it, but it would limit what parts of the world you could see.  As you grew older and gained experience some of those holes would fill in, while others would expand.  When I was a child birthday presents were very prominent in my filter, while taxation was almost invisible to me.  It’s rather the opposite now.

This filtering is necessary because we cannot possibly pay attention to everything around us, all the time.  This would be overwhelming.  It also must be a passive process, because we cannot stop the flow of information and take time deciding what to take in and what to ignore.  The world is constantly offering us new things to notice.

Software development is an intellectual process, something we do with our minds.  The filter that our assumptions impose also effects how we do our job, and this includes anything we have determined to be impossible.

It is a common belief that the design of a system always includes a cost vs. benefit determination regarding complexity and flexibility.  To make a system more flexible, this belief asserts, requires more complexity, more effort, and more time.  This increases cost not only in the initial creation of the system, but also in testing and maintenance.  Flexibility is a good thing, but many believe you cannot achieve it for free; you will always pay for it in terms of increased complexity.

Or, to put it another way, a common belief states that it is impossible to achieve an increase in the flexibility of a system without adding to its cost.  This is not true.

It is certainly possible to incur an increase in complexity in the pursuit of greater flexibility, but it is not necessarily the case.  Not only is it quite possible to make a system more flexible without increasing its cost, we can often achieve greater flexibility and at the same time reduce the costs incurred.

If you accept this as possible, even without knowing precisely how to accomplish it, you will have changed the way you filter the information that you take in.  You will begin looking at things like the open-closed principle, the inversion of control, and design patterns (especially the creational patterns) in new ways.  You will begin to find examples where you can save yourself time and effort (both in terms of implementation, but also testing and maintenance), and yet achieve greater flexibility in your design.  The more you look, the more you find.

This is the butter-zone of good design.  It is, in fact, one way of defining what good design is.  A lot of what we do at Net Objectives through our training in analysis, design, and testing, is to demonstrate in clear and concrete terms exactly what this kind of design is.

It is not more design; it is different design, and often less that achieves this advantage.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban