Know Thy Domain

Devs have so much to keep up with these days.  To be effective a good dev needs to work within the “full stack”.  To make things difficult, new tech is introduced daily on the entire stack – operating systems, web servers, databases, client and server-side programing languages and user interfaces.   One of the most important is the user experience – the user interface that can make or break a site’s popularity.

We have to be experts in our own domain.

But that is only half of the challenge devs face.  We need to be experts in our client’s domain as well.  Whether it is healthcare, engineering, biology, transportation, construction – you name it, we have to become experts in those domains as well.

We have to be experts in the client domain?

Why?  Because many projects fail when devs don’t know enough to ask the right questions to get to the real client requirements.  Recently I took a “Biology for Non-Scientists” class (it was excellent by the way).  The instructor made a curious statement, “IT people have a tendency to not fully understand what the experts know or want and they go off and develop the wrong answer, biology is much more complex than they believe it is…”  WHOA! I usually hear those kind of words from business people, not biologists!  So we really do have a problem across the board.

We should spend more time fully understanding where our clients are coming from, what kind of experience they need and what problem they are trying to solve when they come to us.  There are lots of ways to approach this – pick your favorite or the most appropriate for the project – agile, extreme programming, joint application development, rapid application development and others.  The point of these methods are to help flesh out the problem in enough detail to all parties involved in the project to successfully complete the project to the client’s liking – which means you tackled the right problem!

In my experience, no matter what method you use, be sure to have the client tell you, in at least two discussions in succession, that they are satisfied with the solution.  You should be able to present the problem and the solution in enough detail to make all stakeholders comfortable to take the next step in the development cycle.  As requirements or designs are changing as your discussions progress, your should not conclude that phase of the development approach.  Yes, you are under pressure to deliver on a schedule.  Yes, the boss is breathing down your neck asking when you think you will be finished so you can get on the next project.  It is most important to focus on getting to the bottom of what the client needs – but don’t take too much time!

You will always learn something new in the software development business.  Whether it is your domain or the client’s.  Either way, it’s yours.

Copyright © Kerr Systems and Services 2017