In my previous blog, I talked about the idea of GDD, or Goal-Driven Development. It is a philosophy that individual programmers can apply to their daily work. I derived it from my experience with successful meetings, then from successful teams, then finally down to great programmers:
Great programmers have clear, actionable, and attainable goals, and every task directly works to accomplish a goal.
GDD is something that developers on Agile projects have a lot of experience with. In the case of Agile, stories must be well defined, attainable, and have very specific criteria to be considered a success. The way to actualize the story is by creating tasks, bugs, sub-stories, etc.
That strategy works very well for Agile, and can be applied to the way a developer thinks about their daily routine. At any time during the day, someone should be able to walk up to a developer and ask them what they’re trying to accomplish right now. There should always be a clear understanding by the developer that they are coding a solution so a goal can be met. We should not code for the sake of coding on someone else’s dime.
This strategy also works for problem solving sessions. It is often necessary to bring together a group of developers to talk through the solution to a complex problem. If often happens during these sessions that one extremely hard piece is discussed and dissected extensively. The tunnel vision on fixing that piece is frequently a good thing, but can easily spiral outside of the original discussion.
I’ve been in many, many meetings where one small aspect dominates the conversation. By the end of it, the original goal of the meeting was not met. One piece of it may be complete, but the overall meeting was a failure.
There are two possible solutions to this problem. The first is that the organizer of the meeting should have seen this problem area, and focused the meeting only on that. This strategy is short-sighted because the most difficult pieces of a programming puzzle may only be discovered through a large amount of research or deliberation. The hardest parts to code are often the hardest parts to see beforehand.
The second solution is to pause the discussion as soon as it starts to veer away from the meeting’s goal. If the two or three coders that are discussing the minute detail are able to clearly explain how this needs to be talked about right now, then the discussion should continue. The most frequent outcome of the question is that the few who understand the issue should discuss it outside of the current meeting. That way the problem is resolved, and the meeting can continue towards reaching its goal.
This strategy also works well in code reviews. When someone is explaining their code to me, I frequently have dozens of possible fixes run through my head. Missing semicolons, refactoring one method into two, or changing a name are the most frequent. Rather than bombard the author with countless suggestions, I focus in on the changes that will get them as close to accomplishing their goal as possible.
I also use this when I see some section of code that I know does not accomplish their goal. By making someone talk through how those statements get them closer to their goals, several things quickly become clear to them. The act of converting abstract thought into a concrete conversation makes issues obvious to both the speaker and listener.
The best principles in life are usually the ones that work in many different scenarios and settings. GDD works on both a micro and a macro level. The examples I’ve given above are just a few that come from my personal experience with it. I will occasionally add blogs on this topic, but this blog and the previous should function as the primary resource for what GDD is and why it works.
The post Goal-Driven Development Continued appeared first on Zach Gardner's Blog.
