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.
Monday, November 14, 2011
Tuesday, November 1, 2011
Why do POs ignore all the 'other' stuff
I pulled a quote from this post: http://www.jrothman.com/blog/mpd/2011/06/do-you-have-feature-itis.html
"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.
"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.
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.
Friday, July 29, 2011
Organizational Branching (Feature or Abstraction)
There has been some recent interesting commentary by Martin Fowler and Jez Humble on the use of features branches in DVCS systems. Specifically Fowler started the conversation with this post on Feature Branches.
It was during my reading of Jez's commentary in his recent post that I had a little light bulb moment about management of organizations in relation to the blog topic.
So the light bulb moment I had related to how companies I have worked for tend to address specific 'project/program' needs within the organization. My observation was this: Companies tend to "Feature Branch" the organization as a way to attempt to accomplish a specific project/program, i.e. new teams or new groups are formed to handle high level work items for the organization.
I believe that organizations run into a great number of the same issues associated with feature branching code when they split their org. structure to do work in this way. Breaking off a new group invites Conway's Law issues and shoves a 'wedge' between the body of the company and this newly formed entity. The new entity slowly stops conversing with the organization - they become disconnected from the needs, the new teams stop being able to really effectively know that what they are developing is helping. The only way to combat this tendency to to have the new org occasionally "merge" what they are doing with the larger organization. If too much time has passed between this merge and the last merge that occurred (Status meeting, conversation or other people synchronizations) then the new team may have developed their software considerably far down a path that is not useful to the organization as a whole - making the merge efforts difficult at best.
Following this analogy I am curious if there is an argument to be made about branching the organization by abstraction, similar to how code might be branched by abstraction. I believe that this would look like having work stories divvied up amongst a bunch of pre-existing teams. Some of the teams may have an expertise in a given area but would be more generalist in nature. This would keep the teams engaged and involved in what the reset of the organization is doing and accomplishing, no thought merging required.
Very interested in any of your (dear readers) experiences or thoughts - this is just something I have been mulling around in my head about how the business of software development works.
Comments...
It was during my reading of Jez's commentary in his recent post that I had a little light bulb moment about management of organizations in relation to the blog topic.
So the light bulb moment I had related to how companies I have worked for tend to address specific 'project/program' needs within the organization. My observation was this: Companies tend to "Feature Branch" the organization as a way to attempt to accomplish a specific project/program, i.e. new teams or new groups are formed to handle high level work items for the organization.
I believe that organizations run into a great number of the same issues associated with feature branching code when they split their org. structure to do work in this way. Breaking off a new group invites Conway's Law issues and shoves a 'wedge' between the body of the company and this newly formed entity. The new entity slowly stops conversing with the organization - they become disconnected from the needs, the new teams stop being able to really effectively know that what they are developing is helping. The only way to combat this tendency to to have the new org occasionally "merge" what they are doing with the larger organization. If too much time has passed between this merge and the last merge that occurred (Status meeting, conversation or other people synchronizations) then the new team may have developed their software considerably far down a path that is not useful to the organization as a whole - making the merge efforts difficult at best.
Following this analogy I am curious if there is an argument to be made about branching the organization by abstraction, similar to how code might be branched by abstraction. I believe that this would look like having work stories divvied up amongst a bunch of pre-existing teams. Some of the teams may have an expertise in a given area but would be more generalist in nature. This would keep the teams engaged and involved in what the reset of the organization is doing and accomplishing, no thought merging required.
Very interested in any of your (dear readers) experiences or thoughts - this is just something I have been mulling around in my head about how the business of software development works.
Comments...
Thursday, March 10, 2011
Carrots, Sticks, Stones and Management
So - I have been involving myself quite a bit recently with reading and doing presentations to the people that I work with. A recent presentation that I gave was on process and why it matters in the work place. Now - I know what some of you are thinking, NO I have not gone off the deep end and YES I still rail against the Process = Progress models that are occasionally touted by the places I have worked for and "Big Co." in particular.
So - what sparked the presentation in the first place? Well, I viewed the following TED Talk by Daniel Pink on the science of motivation. I also had the opportunity while I was putting the presentation together to read Freedom from Command & Control: A better way to make the work WORK but did not immediately incorporate the ideas of work FLOW from the book into the presentation. Let me focus in on the TED talk as I think it relates to programming.
Carrots
Companies all over the US have been set up for a long time to essentially offer Carrots to their employees. In essence every company I have worked for has a bonus program which is based on some amount of performance that is usually measured by an individuals manager and is more measured by gut feel then by a strict "You got it over the line" type of measurement. Companies attempt to make each "goal" for the year that an individual will do to get their full bonus a S.M.A.R.T. goal - one which is:
Specific
Measurable
Attainable
Realistic
Timely
Which is interesting because it teaches people to game the "Specific" part to be as small as possible so that in the end it is "Attainable". People end up being taught to think IN the box rather then out of it - or risk getting screwed out of the money that they may feel they rightfully deserve. So whats wrong with this Goal/Bonus system?
As Daniel Pink pointed out carrots (Rewards in a do this and I will give you that regime) work very well for anyone not doing 'creative' or 'problem solving' work, in fact they work very well helping people to move faster and do more when the work is easily repeatable or rote in nature.
These types of carrots or monetary incentives however prevent people from being able to use the thinking and creative sides of their mind in order to problem solve. The rewards have a tendency to NARROW the mind which in the end prevents people from seeing more creative "outside the box" type answers to problems. In fact when people were presented problems requiring even rudimentary problem solving skills the time taken to solve the problem increased rather than decreased. Plenty of science to back that up - and yet every company I have worked for still dangles these carrots as if they were something grand and great that you get for working for "Big Co." when really I have come to see them more as a pain in the ass and not as important as the type of work I am going to do or the environment I happen to work in.
Sticks and Stones
A few people have noted to me how much they HATE getting yelled at. For a very narrow band of people the idea of getting admonished by someone is a motivator. I would venture that in today's work place that this behavior by managers or staff isn't tolerated very much at all. I believe that you do still find people that believe that by being an asshole or the office mad man they get results and motivate their people to be better and produce more but I am fairly sure that this only works on people that have fairly low self esteem to begin with, everyone else leaves or quits and goes on to find a better environment or boss to work for and with. Fear of reprisal, similar to adding incentives to creative work, works to de-motivate staff and make them think twice about moving to a new position elsewhere.
What does this all have to do with Management?
Management
Typical management that I have been associated with lives in a world where the hierarchy is king, and their command and control may not really be questioned. The HR department works with management to set up 'Carrots and Sticks' to make sure that workers keep themselves in-line and 'producing' the things that make the company money. The problem is that as software developers we are not building cogs, nor producing cars - we are inherently doing something that requires each and everyone of us to think about what we are doing. We have to spend time asking questions and thinking critically about what we are doing and why. We 21st century workers are much more interested in Autonomy, Mastery and Purpose then we are specifically about the dollar figure. Management has to move to take the conversation about money off the table by paying workers in a way that makes the worker comfortable so that the company can get more performance from the staff and to engage in conversation about the things that really matter when it comes to jobs like software development.
Nothing motivates a software developer better than being told:
1) You have the ability to work when you need to, from home or from the office as long as you get done the work required. Autonomy to work w/ teams in the way that everyone decides rather than in the prescribed way a manager feels is best is a wonderful motivator.
2) Most software developers pride themselves on the Mastery of the software development craft of one or more software development languages. Developers like to share their knowledge with others and take pride in producing cool things that the world uses. Managers should encourage and support this by helping your software development staff to get smart and stay that way.
3) Context is everything. Software developers rail against doing something when they don't have the context for why they are being asked to do it. Not being given this information is a huge de-motivator for most software developers that I know. Context is king and is vitally important to making the software being developed manageable and maintainable over time.
The days of Carrots and Sticks are now done and gone - OH SO 20th century at this point. We need to listen to the science and attempt to find the 21st century motivational equivalents, things like Autonomy, Mastery and Purpose so as to reshape the companies we work for and with and the managers the help run them.
So - what sparked the presentation in the first place? Well, I viewed the following TED Talk by Daniel Pink on the science of motivation. I also had the opportunity while I was putting the presentation together to read Freedom from Command & Control: A better way to make the work WORK but did not immediately incorporate the ideas of work FLOW from the book into the presentation. Let me focus in on the TED talk as I think it relates to programming.
Carrots
Companies all over the US have been set up for a long time to essentially offer Carrots to their employees. In essence every company I have worked for has a bonus program which is based on some amount of performance that is usually measured by an individuals manager and is more measured by gut feel then by a strict "You got it over the line" type of measurement. Companies attempt to make each "goal" for the year that an individual will do to get their full bonus a S.M.A.R.T. goal - one which is:
Specific
Measurable
Attainable
Realistic
Timely
Which is interesting because it teaches people to game the "Specific" part to be as small as possible so that in the end it is "Attainable". People end up being taught to think IN the box rather then out of it - or risk getting screwed out of the money that they may feel they rightfully deserve. So whats wrong with this Goal/Bonus system?
As Daniel Pink pointed out carrots (Rewards in a do this and I will give you that regime) work very well for anyone not doing 'creative' or 'problem solving' work, in fact they work very well helping people to move faster and do more when the work is easily repeatable or rote in nature.
These types of carrots or monetary incentives however prevent people from being able to use the thinking and creative sides of their mind in order to problem solve. The rewards have a tendency to NARROW the mind which in the end prevents people from seeing more creative "outside the box" type answers to problems. In fact when people were presented problems requiring even rudimentary problem solving skills the time taken to solve the problem increased rather than decreased. Plenty of science to back that up - and yet every company I have worked for still dangles these carrots as if they were something grand and great that you get for working for "Big Co." when really I have come to see them more as a pain in the ass and not as important as the type of work I am going to do or the environment I happen to work in.
Sticks and Stones
A few people have noted to me how much they HATE getting yelled at. For a very narrow band of people the idea of getting admonished by someone is a motivator. I would venture that in today's work place that this behavior by managers or staff isn't tolerated very much at all. I believe that you do still find people that believe that by being an asshole or the office mad man they get results and motivate their people to be better and produce more but I am fairly sure that this only works on people that have fairly low self esteem to begin with, everyone else leaves or quits and goes on to find a better environment or boss to work for and with. Fear of reprisal, similar to adding incentives to creative work, works to de-motivate staff and make them think twice about moving to a new position elsewhere.
What does this all have to do with Management?
Management
Typical management that I have been associated with lives in a world where the hierarchy is king, and their command and control may not really be questioned. The HR department works with management to set up 'Carrots and Sticks' to make sure that workers keep themselves in-line and 'producing' the things that make the company money. The problem is that as software developers we are not building cogs, nor producing cars - we are inherently doing something that requires each and everyone of us to think about what we are doing. We have to spend time asking questions and thinking critically about what we are doing and why. We 21st century workers are much more interested in Autonomy, Mastery and Purpose then we are specifically about the dollar figure. Management has to move to take the conversation about money off the table by paying workers in a way that makes the worker comfortable so that the company can get more performance from the staff and to engage in conversation about the things that really matter when it comes to jobs like software development.
Nothing motivates a software developer better than being told:
1) You have the ability to work when you need to, from home or from the office as long as you get done the work required. Autonomy to work w/ teams in the way that everyone decides rather than in the prescribed way a manager feels is best is a wonderful motivator.
2) Most software developers pride themselves on the Mastery of the software development craft of one or more software development languages. Developers like to share their knowledge with others and take pride in producing cool things that the world uses. Managers should encourage and support this by helping your software development staff to get smart and stay that way.
3) Context is everything. Software developers rail against doing something when they don't have the context for why they are being asked to do it. Not being given this information is a huge de-motivator for most software developers that I know. Context is king and is vitally important to making the software being developed manageable and maintainable over time.
The days of Carrots and Sticks are now done and gone - OH SO 20th century at this point. We need to listen to the science and attempt to find the 21st century motivational equivalents, things like Autonomy, Mastery and Purpose so as to reshape the companies we work for and with and the managers the help run them.
Wednesday, February 23, 2011
Of Builders, Leaders and Bosses
I was recently reading a post by Umair Haque on the Harvard Business Review website and to be honest it struck a chord with me.
For the last few years of my career I have been actively working to:
1) Better myself by introspecting on what I am good at as well as listening carefully to the feed back that people and managers I have had are providing to me
2) Change/Effect Change in the places that I work. It is my attempt to make the places I work better for my having worked for them (a workers boy scout rule if you like)
The post stood out to me because, in my own twisted little mind, it put to words exactly what I attempt to be and do when I work for a company. I am not the boss, someone who inspires and instills fear into the people that work for her. I am not the leader, someone who specifically works to inspire. I am the builder, someone who IS inspired to change the world I live and work in, for the better, in whatever way I can.
My desire is clearly present in my relentless effort to get companies to realize that software development is first about the USERS of the tools being built and after that is about HOW the software gets built. I seek to get the places I work for to realize that internal quality is not a compromise that should be made or even can be made in order to get faster. I work relentlessly to get managers to understand that they can dictate or indicate the WHAT of software development but that they should never attempt to control, in the strict sense, the HOW of the software development process. I work to get teams to understand that they can and SHOULD work to change the how of their work each and every day - nothing will get better when the teams just sit idle by and let others tell them how the world should be.
I am a builder - inspired by changing the world (in my own small ways), showing people WHY each and every day - What are you, a boss, a leader or a builder?
For the last few years of my career I have been actively working to:
1) Better myself by introspecting on what I am good at as well as listening carefully to the feed back that people and managers I have had are providing to me
2) Change/Effect Change in the places that I work. It is my attempt to make the places I work better for my having worked for them (a workers boy scout rule if you like)
The post stood out to me because, in my own twisted little mind, it put to words exactly what I attempt to be and do when I work for a company. I am not the boss, someone who inspires and instills fear into the people that work for her. I am not the leader, someone who specifically works to inspire. I am the builder, someone who IS inspired to change the world I live and work in, for the better, in whatever way I can.
My desire is clearly present in my relentless effort to get companies to realize that software development is first about the USERS of the tools being built and after that is about HOW the software gets built. I seek to get the places I work for to realize that internal quality is not a compromise that should be made or even can be made in order to get faster. I work relentlessly to get managers to understand that they can dictate or indicate the WHAT of software development but that they should never attempt to control, in the strict sense, the HOW of the software development process. I work to get teams to understand that they can and SHOULD work to change the how of their work each and every day - nothing will get better when the teams just sit idle by and let others tell them how the world should be.
I am a builder - inspired by changing the world (in my own small ways), showing people WHY each and every day - What are you, a boss, a leader or a builder?
Subscribe to:
Posts (Atom)
