Following a business process approach to implementing an EHR for behavioral health agencies includes taking the right approach to software development.
In order to write the code…
At my first couple of jobs as a developer, my mentors were both smokers. Most times, I would go out with them for discussions. Every time we went out, that’s when the real work was happening. We would evaluate and hash out multiple ways that a problem could be attacked, come to a well thought out solution, then return to execute. Whenever we would get stuck with an issue, going outside and stepping away was more productive than just banging away sloppy code frantically without stepping away and really allowing ourselves the space that we needed to think as clearly as we were capable of.
These principles have never been more important than when I joined the world of EHR software development, only now these smoke breaks have been replaced with what I will refer to as spontaneous design meetings. A lot of times we need to call on and interrupt our peers at the spur of the moment in order to do “what-if” analysis, get more ideas, call on a devil’s advocate, or simply come up with a whole new approach to what we are trying to accomplish. This may interrupt every other programmer’s project/story, but is a necessary activity in order to keep the best of many minds integrated into the design and final product. Solve the problem, then write the code.
This is why peer programming (https://en.wikipedia.org/wiki/Pair_programming) is such a hit in the world of agile development (https://en.wikipedia.org/wiki/Agile_software_development). Two minds attacking a problem or story are more likely to produce higher quality results than one. If anything, one of the developers will walk away with a better and more experienced perspective. This is where working with a mentor has helped me the most.
Another way of getting a problem solved first is the ability to set aside a story for a day or so, and work on something else before further attacking the problem. I can’t even count the number of times that I’ve exhausted every idea that I had at the end of a day, only to come in the next morning and have a “Eureka!” moment almost immediately. That moment can also happen while driving home, getting ready for bed, or getting ready to go back to work. It’s the fact that sometimes you can’t see the obvious answer when you’re up to your neck in it. You need to see it from the outside. There also may be problems that you haven’t even considered until you come back to it with a fresh and clear mind.
… You need to solve the problem
The “why” for the software request is the most important thing for a developer to know. There are many things to be taken into consideration when planning to develop new functionality. A developer knows many things about the current software that the user and/or customer team member does not. The developer may know of a much simpler solution, but without knowing the why, they don’t have the chance to draw the appropriate conclusion. If the developer is given the chance to first solve the problem with the real scenario in mind, they will be much more confident, productive, and aware of what to consider and look out for while writing the code.
I once worked with a developer who graduated with a bachelor’s degree in philosophy. I used to think that this was an odd transition, but his capacity to understand abstract concepts and truly think was not surprisingly an advantage in the world of computer science. In the world of agile development, there is no developer that simply writes code. We gather requirements from a customer team, analyze, design, develop, and maintain that software while constantly refactoring (refining) what code already exists to best coexist with what’s currently being developed. To simply take specifications and develop exactly what is asked would not take full advantage of our insight into what’s going on behind the scenes. We need to know the problem we are being asked to create a solution for in order to analyze and plan efficiently.
There was once a story that requested a specific set of calculations to be done in a grid. The amount of time to do so in an efficient manner would have taken days. It occurred to the developer that he did not know the reason that he was adding this feature. Upon further questioning, he discovered that the reason was so that the user could draw a conclusion that there was already a simple flag in the database for. By using this flag instead of spending days optimizing an expensive calculation, the developer saved approximately 2 days of development time. All because he questioned the reason for what was being requested.
This process of stepping back, thinking heavily about, and possibly questioning what is to be done in order to solve a problem is far more important than being able to just do what one is told without question. A developer needs to know the whole story in order to first solve the problem. Then that developer can effectively write the code.
If you liked this, you may also like Progress notes and bank checks have more in common than you think.
