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.
Tuesday, November 1, 2011
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...
Subscribe to:
Posts (Atom)
