Monday, November 14, 2011

Death and Craftsmanship

I have been thinking a great deal about software craftsmanship recently. I have Uncle Bob Martin to thank for making me at least think about it. There is however a life event recently that made me consider the topic in a deep way that I am not sure I really even considered before; you see I had been taking what Uncle Bob was saying about software craftsmanship at face value that is until my Grandfather passed away this weekend.

The Craftsman

When I was younger I used to go over to my grandfathers house, which was not to far from my own home, about 2 or 3 times a month. At the age I was at the time - going to his house was about being able to spend my summer in the pool that my grandparents had, it was about having breakfast, lunch and dinner on the porch, it was about the grill and the amazing food that my grandfather could concoct using it. The time that I spent at my grandparents house was rarely about the things that my grandfather did for work or what he had done as work because my interaction with him was mostly after he retired from the work a day world.

To my knowledge my grandfather worked for Boeing as a machinist making various parts and pieces for either helicopters or for the machines that were machining other parts for the same. What I didn't know until I got older is what an amazing skill my grandfather had for doing what he did - I did NOT realize what a craftsman this man was. You see, my grandfather was able to make the machines he worked with sing and dance to create very specific parts. He was able to set up lathes and other machinery to sharpen existing tools, or create something totally new. My grandfather was able to cause these machines to create parts that had tolerances in dimension of no more then a few 10,000ths of an inch, by hand, day in and day out. When he learned how to do this work he didn't have a CNC machine to program, things were not automated in any significant fashion, he was taught how to make these machines do his bidding by hand, with the lightest of light touches. My grandfather took great pride in what he created - in retrospect, I have that same pride now for what he accomplished doing that work.

Software Development

My grandfathers death and the realization of the talent he displayed when working with machining metal lead me to this, I don't think that my software design and programming should be any different. I should be able to perform gross cutting code as well as fine grained 10,000ths of an inch type code and have it all work. I should be able to call myself a craftsman of software by being able to have someone look at what I have done and say that it is complete and well done. Software craft-persons should be able to look at someone else's work and identify their own craft in it as well as to call out the simple and small foibles made by their compatriot craft-person. Performing the 'craft' of software development, turning ideas into code and doing it with quality and precision, is not easy and not everyone can do it - just like I can't do the things my grandfather did with his machines. However - practice, apprenticeship and other things that go with thinking of software as a craft to master can help you improve what you do, can improve how you think about the work that is software development.

I know from here on out I will be striving to be NEARLY the person that my grandfather was, and nearly the craftsman I know he was in his work. I will work every day to improve how I write my software because knowing who my grandfather was and how he did his work prevents me from doing any less.

Tuesday, November 1, 2011

Why do POs ignore all the 'other' stuff

I pulled a quote from this post:

"But with that feeling of excitement must come a feeling of responsibility. Not only is the PO responsible for the product features, the PO is responsible for the business value of the product, and knowing that the team is able to continue to extend the system. Without architecture, tests, all of the necessary engineering practices that good software requires, a technical team cannot deliver."

If you combine the above quote with this talk by Theo Schlossnagle from OmniTI @ the Velocity conference this year I think some interesting things arise.

1) We should as software engineers stop hiding the work we are doing to better the systems we work with from our product owners.

Product owners need to understand the system that they are asking for features in, they have to understand it at a rather fundamental level so that they can treat the software being developed as an asset of the company, as a primary delivery platform. If the Product Owners do not understand their system, they may end up surprised when features that they ask for take a very long time to develop. Understanding the system means that there WON'T be any surprises when the engineers come back with their estimate of how long it will take to accomplish something. If we stop hiding the 'care and feeding' of the system the product owners are adding features too they can be fully informed when they make decisions.

2) It is fine to be the Chief Get it fucking done officer

Provided that you have the ability to both take accountability and to justify what is being done - just GETTING something done is better then talking about it all day long. Sometimes you have to start somewhere just as a way to see if where you are going is either possible or realistic.

3) Being a good software engineer means not settling

When I say not settling I mean, not settling for being pushed into doing a lessor job then you think you should be doing. Most developers that I have run across in my 'shortish' career know when they are taking short cuts and they 'KNOW' when they are hurting the codebase to get an ENDS that is being asked for. If this can never be addressed bad things can happen - and the amount of time that it takes to do development in a given codebase will begin to lengthen till eventually people are calling for a re-write rather than a new feature.

Please POs stop ignoring all the other good things that the developers want to do to help the codebase they work with, please developers stop hiding the work you want to do to maintain the codebase from the POs - development will be a much better place if we can just do this 'little' bit.

The myths we buy into

Someone I work with posted this link:

One of the more interesting quotes from that article...

"As a boss, your energy has a disproportionate impact on those you lead, by virtue of your authority. Put bluntly, any time your behavior increases someone's anxiety — or prompts any negative emotions, for that matter — they're less likely to perform effectively.

The more positive your energy is, the more positive their energy is likely to be, and the better the likely outcome. "

If you are working under constant and continuous pressure to 'perform' no matter what your position or job, your manager may be making a short sighted mistake where your decision making may be compromised as a result.