I’m often amazed that Dilbert is popular enough to be on the front page of the comics – in a way, it’s sad that there are so many “pointy haired bosses” in the world that a comic like this would be tragically funny for so many people:
It’s no wonder that process is a four-letter word – if the motivation a business has for investing in process is to reduce the jobs involved to a lowest common denominator, then it deserves that reputation. My early impressions of process advocates were that they were people that needed process to protect them – to be blunt, they were the lowest common denominator, so they had the most to gain by having process in place.
This opinion put me in a very awkward position as I started to tackle management roles. For a leader, process is one of the tools you use to do your job. If I couldn’t figure out how to reconcile this with my personal opinions about process as an individual contributor, then I would very likely fail as a manager. You may find yourself in a similar situation, and it may even be why you are avoiding a leadership role.
What I wanted to find – my holy grail – was a process that made the best people on your teams even better. In fact, if I could find a process that had popular support with the most talented on the team, then that was the process I wanted to understand and advocate. What I wanted to find was a process that brought structure, discipline, and predictability to an activity that is naturally chaotic. I also needed to better manage the expectations of others outside the product development organization and combat their desire to build a “shared fiction”. Finally, I needed a process that I would be willing to follow myself as I am terrible at convincing others of something that I do not believe or practice.
North Shore - Lake Superior, MN
The answer for me were iterative and incremental development techniques now known as Agile. Every organization I have worked with has met this challenge with skepticism and a certain amount of fear. Marketing and product management have to learn to let go of their fear that product development won’t deliver unless a hard contract is extracted up front. Development needs to work hard to master the practices, but more importantly, each person on the team has new obligations to step up their game as technologists and improve their design and coding skills. Proper application of the practices brings rhythm to the operation, ensures that meaningful work is ready at all times, and drives the individuals involved to improve their skills and to deliver high quality product on-time.
I’ve just finished another great book to recommend: “Practices of an Agile Developer” by Venkat Subramaniam and Andy Hunt. This book is designed to teach the individual team member more about the practices expected of them to contribute to an Agile team. It focuses mostly on the technical disciplines of test and development, but it does a great job of setting the bar high for these team members in furthering their development as effective engineers. I’ve added it to the “must read” list for technologists involved in Agile and would suggest that it is probably the best primer I have read so far for explaining to that audience what they need to learn.
I’m currently working with a client on a project that includes a fair amount of development effort for me, so I’ve had the opportunity lately to “practice what I preach” and to apply the principles of unit testing and test driven development while also trying to “Program Intently and Expressively” and to “Attack Problems in Isolation”. This hasn’t been easy as the project is for a mobile platform and the tools and architectural practices available there are not nearly as mature as for server development. I’ve had to put in quite a few extra hours of time to invent patterns that make sense and allow for typical unit testing to occur, but it has all been worth it and I really like working in the code base after making these investments.
Even after all these years of development, there are still “Aha!” moments where I realize that I have really LEARNED something. Here’s a great example – yesterday I was working on a class where I had used the usual rules of encapsulation to hide the implementation of internal data structures. I do this out of habit and as a good practice, but I admit to being skeptical that it ever really pays off – after all, how often do you go into a class and re-plumb the internal implementation without affecting the interface? Then I hit the point where my next feature to implement was to be able to store and retrieve a collection of these objects from storage. The class had a couple of private members that were Date objects, and for some reason the Date object in the mobile class library I had available did not implement Persistable.
Argh… However, dates can also be stored as longs, and it turns out that this intrinsic data type is Persistable. A couple of quick changes to switch my private values from Date to long and a little work in the setters and getters to do the conversion and I now had a Persistable class with no impact to any of the code that used it. Some of the code even shrank – this class also implements Comparator so that it can be used in sorted lists, and now instead of needing to convert the Date to a long so I could compare them, I could now just use the long values that were there.
Sweet! The simple truth – this was possible because I had been focusing on unit testing this class and the practice of building those tests had helped make sure I had a clean interface into this class. Also, one click later and all of the unit tests for the class passed and I knew that I had not broken any of the functionality of the class. It’s was such a simple but powerful example that I know that if you ever experience something like it yourself, you’ll become a convert.
Ping! Finished another one.
Time for another pellet…
