product

You’re Too Close

Have you encountered the following scenario?

You are trying to solve a problem (or helping solve a problem) and know or at least think you know the solution.  You are in the middle of implementing it when someone else looks at it and says, “why don’t you do it this way, isn’t this way easier/better?”  Taking a step back, you realize that the question not only has merit but is a better and much more obvious solution; you can’t believe you missed it.

What happened?

I think its because you were too close to the problem and had developed a very narrow focus.  That narrow focus prevented you from seeing the better solution.  Perhaps this is even a variation of functional fixedness in that we’ve latched onto an idea of how to solve a problem and our mind’s may not see alternatives easily.

What can we do?

  • Think about the broad (or product) level goals regularly.
  • Entertain questions and/or suggestions from others.
  • Ask: “Is this the best way?”
  • Ask: “Is this the practical way?”
  • Don’t overthink the problem.
  • Get it working then evaluate the solution and/or do a code review!
Posted by Chad Dotson in Doing Things Better, Programming, Tips, 0 comments

Make It Easy

Building a successful product is usually complicated business.  With any luck a project will have an automated deployment process.  This however is only part of the equation.  Another significant part would be an automated build process.

Long Term Success

Long term success means making it easy for new people to get started in the weeks/months/years following a project’s startup.  Imagine the following project in two different scenarios.

The project is a large scale application with several dependencies.

Scenario 1 (No automated configuration and build process):

  1. Check out project from source control.
  2. Perform configuration needed for dependencies.
  3. Build / Install each dependency separately.
  4. Perform configuration needed for product build.
  5. Build product.

Scenario 2:

  1. Check out project from source control.
  2. Build product.

Which of those scenarios is more straight-forward and easiest to work with?  It’s pretty easy to see that scenario 2 is the best.

Memory and Documentation

In addition to helping new team members get started,  automated builds can serve as a form of long term memory.

“How do I do that?” becomes “press build.”

“How does that work?” becomes “check the build script.”

Posted by Chad Dotson in Key Concepts, Programming, Software Engineering, 1 comment