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.
Post a Comment