Maybe We're Asking the Wrong Questions

October 28, 2014 — Posted by Al Shalloway

I've been doing a variety of presentations at all levels the last week and it occurred to me that there are a few questions I ask that tend to get deep answers that many folks seem to think not possible. I thought I'd share a few of them and ask for others to chime in.

While I don't think software development is easy, I believe we make it a lot harder than it needs to be. I think much of it is because we act as if we know much more than we do. We continuously act with hope over experience - that this time we understand, this time we know what to do, this time we are building the right thing correctly. We act as if we are certain of virtually everything when our experience shows otherwise. Given our passion and confidence in ourselves (good things) I have found that we can adjust our thinking by asking questions. These are not hard questions nor are they difficult to answer. But asking them seems to avoid many of the challenges we face all of the time. Here are four for developers to ask at different times:

When getting requirements from a product owner or product manager: How will I know I've done this?  This changes the nature of the conversation and has the person stating the requirement get very specific. I have found it both gets clarity on what is needed while improving the communication of all parties involved.  It is a very easy form of Acceptance Test-Driven Development.  I would bet dollars to donuts that had you asked this question when getting requirements where later the person said "that's not what I meant" when you showed them what you built, that you would have understood much more than you did.

When designing something: How would I design this if later I discovered that however I designed it it would be wrong?  I, unfortunately, have a lot of experience with this happening.  The answer is somewhat clear - encapsulate whatever it is that you are not sure about. When you do this a few things will happen.  It will clarify to you what you know and don't know.  But more importantly, when you do find out you designed it wrong, you will have an easier time of refactoring to what you should have done.  Also, knowing what you build is going to be wrong means you can build a really simple implementation of what you are encapsulating.  Maybe even mock it.

When writing the implementation for something. If I have to change this in the future, what else will I have to change?  I, unfortunately, follow Shalloway's Law - when N things change and N is greater than 1, Shalloway will find at most N minus 1 things. Asking this question follows Shalloway's Principle - avoid situations where Shalloway's law applies.  It's amazing how much your code can be when you design your classes so that the compiler or linker will generate a "to do" list for you.

When creating a class. How will I test the methods in this class? (ask this before writing any code for the class).  It is amazing how much this will improve the quality of your classes.  Doing this make your code much more testable and testability is highly correlated with high quality code.

What's important to notice is that asking and answering these questions takes very little time but creates great value.

Like these questions?  You can get more in depth discussions by picking up our book - Essential Skills for the Agile Developer - A Guide to Better Programming and Design.  We're also building an online course covering the book. Let me know if you are interested in that or any of our technical courses.

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile 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