The view of development of software is often similar to the creation story. G-d, as the developer, sets a project schedule (seven days) which is of course padded by about 15%. He completes the project on time, which I attribute to the lack of QA (disease, war, hate, bacon being unhealthy as notable defects). Like all good developers, he goofs off on the last day of the project. And then he's done, and it was good.
Many business managers I have worked with view software like this. Why do I need the development team if the project is over?
Now I'm not arguing against retuning the size of teams against workload.. I'm arguing against the extent to which the business believes cuts can and should be made, which stems from a fundamental difference in perspectives.
See, I view software as a living breathing organism operating in the environment of its users and its problem domain. The developers and technical people who operate,enhance, optimize and extend the software are like the internal organs of the organism..they keep the software alive.
The moment the last developer who knows the code leaves, the code is dead. The time it will take to revive it increases the longer this state of affairs continues.
If you reduce the size of a development team, the ability of the software to react to users, its operating environment, and its problem domain decreases; it will have a harder time evolving and adapting. This relationship between the people who create and maintain it and its ability to change is fairly straightforward..however in today's environment where software is increasingly a service, it becomes ever more relevant.
I think most non technical people view software as an inanimate object or tool that solves a problem..so once it's built and is a part of their world, in their mind it's done...and why would you need a bunch of people to keep working on it?
Now I know most non technical people understand the differences when they take the time to think about it. What I'm getting at is that the intuitive understanding of what code is differs significantly, and that can lead to wide disparity when it comes to making business decisions.
Which brings me to my last point...the value of the original team members. As I've said before, developers aren't fungible. The original team is very valuable....they understand the problem domain, the design decisions and their rationale as well as the code itself. The understanding of the problem and the design is of at least equivalent value to an understanding the code.
The short story is..the more the software needs to adapt, the more critical that the original project team (or a higher percentage thereof) remain intact.
When you can say that the problem domain has settled down, the users have no real demands and the business environment for the software as a service is no longer changing at high speed, well at that point you probably need an absolute minimum... but evaluate the environment for your software and the services it provides before coming to any resource planning conclusions.
Ping me back with your thoughts at twitter/schiff.
Friday, July 24, 2009
Wednesday, July 15, 2009
Thoughts on the business/technology divide
As the software development manager and chief architect for a mid size financial firm, a regular part of what I do is translation between business and technology management.
Despite the fact that more and more is possible, and engineering staff are increasingly productive, the gulf between business and technical management remains one of the most difficult gaps to bridge.
This gulf in understanding is destructive. Business management often views technology projects as opaque and unmanageable ( high risk) Couple that with the expense and it should be no surprise that managers often prefer outsourcing of software projects for cost reasons as well as risk management- an outsourced development which goes awry is a problem for legal..an insourced project is a managers direct responsibility.
The reality, of course is that actually delivering and building software is a complex and difficult game. Doing it across continents, timezones and language/culture barriers doesn't make it easier. If we add in the element of magical or unrealistic thinking coupled with a general ignorance of how building software works...well it starts to be clear why so many software projects fail. In this post, I'd like to touch on my favorite management fallacies. These are in no particular order however they are all favorites of mine.
1) Technical people are fungible
Huge mistake. Most projects are built by 1-5 people, and the best results are generally achieved by several areas of expertise working together. The right team skillset mix makes or breaks a project. Very often, the wrong skill on a task can bring a whole project down.
Projects should be self contained, and if possible all the skillsets required should be present on the team, or assigned for the duration of the project.
2)The project can be completely defined up front
This might be true given enough time and money, however in most cases software evolves over time. The understanding of a business problem at the beginning of a project is often changed by the time the solution appears. This is true of almost any invention - look at bicycles, for example..but in software it happens over the course of its development.
Iteration, and continuous refinement will happen, and should be supported by the management model for projects.
3)Technical people are fundamentally lazy
I sometimes believe that nontechnical managers really believe this, based on the way that project schedules are negotiated. There is never a willingness to consider that maybe the people who have the most direct involvement in writing and testing code are the people in the best position to understand what a given project takes. The fact that a non or semi technical manager has an understanding of the design and implementation does not immediately translate into a true ability to assess the overall difficulty. I have never been in a project schedule review meeting where a non technical manager accepted my schedule. Thus, by long indoctrination, I always pad my schedule.
If anything, in my experience what actually happens is that projects which developers find interesting or believe will be used are underestimated..projects which the reverse are overestimated. Heaven help you if you are a lead and have a boring but mission critical project to get done.
The most important thing you can do to get high performance is to identify work which is truly meaningful to the business and the users it serves, and to keep developers engaged on it in areas that they are good at and if possible mostly interested in.
4) Having QA as part of a development team is letting the fox watch the chickens.
This is one of my favorites, because the underlying assumption is that developers like to ship crappy code. Good developers HATE defects. I have rarely met a developer who, through laziness or a general lack of interest was content to consistently ship defective code. I don't believe developers who operate this way last very long, anywhere. In my experience, most developers are very concerned about testing, and have a deep desire to ship solid code that works and is easy to operate. What they need is help in getting there.
An external QA organization isn't that help..organizationally, its a setup for non stop conflict. Metrics get developed which are used against development and an excuse culture sets in. QA cannot be efficient unless it is staffed by at lease junior caliber developers who can effectively automate tests. Effective automation starts at unit testing and code coverage, so in essence QA starts in development and grows outward as components are integrated. In short, the fox and the chickens are on the same team and likely have very similar technical skillsets in an effectively managed development organization.
Build a product team around developers and testers working together, consistently, around the same code base over time.
5) Putting high pressure on target dates and development managers is what makes projects ship
Or "the beatings will continue".....this is perhaps the worst assumption. You can rarely get good quality work output during the bataan death march.
A business manager can ALWAYS get project schedule concessions through the whole first half of a project from a development manager - through a variety of bullying techniques including -
"If thats the date the project will be cancelled" - it never is...
"Your job is on the line for delivery" - it always is...
"If you can't do this, I'll find someone who can" - possibly, but you'll treat him or her the same way, and nobody is superman
Or my favorite - You gave me an answer i don't like, so I will poll your whole team looking for someone willing to undercut you.
Or last, thats the date, and we'll work the team continuously including weekends to hit it. - never really works.
This approach trains development managers in a technique I refer to as "incremental dissapointment". At the start of planning, a development manager is asked to assess the timeframe for a project. If hes dumb enough to just provide one which is realistic, the bullying will commence.
If hes really dumb, or just starting out in his or her career, he'll hold firm.....in which case he has created an opportunity for a third party consulting firm to quote a better date, or for someone else to lead the project. The smart move is to compromise on a date which the business manager will accept, with conditions that the business owns and will completely undersize (requirements/design review) in terms of time.
This all sounds horribly cynical, but it is a survival model for dealing with dysfunctional business management..remember, the starting assumption coming in is that you and your team are lazy, so you have to be "motivated" properly.
SO my advice to non technical leadership. Trust your technical leadership as a partner..if you don't, find a new partner.
These are just a few of my favorites..next post, I'll be focusing a whole entry on "why do we need developers once the code is written?"
-- Post From My iPhone, typos included
Despite the fact that more and more is possible, and engineering staff are increasingly productive, the gulf between business and technical management remains one of the most difficult gaps to bridge.
This gulf in understanding is destructive. Business management often views technology projects as opaque and unmanageable ( high risk) Couple that with the expense and it should be no surprise that managers often prefer outsourcing of software projects for cost reasons as well as risk management- an outsourced development which goes awry is a problem for legal..an insourced project is a managers direct responsibility.
The reality, of course is that actually delivering and building software is a complex and difficult game. Doing it across continents, timezones and language/culture barriers doesn't make it easier. If we add in the element of magical or unrealistic thinking coupled with a general ignorance of how building software works...well it starts to be clear why so many software projects fail. In this post, I'd like to touch on my favorite management fallacies. These are in no particular order however they are all favorites of mine.
1) Technical people are fungible
Huge mistake. Most projects are built by 1-5 people, and the best results are generally achieved by several areas of expertise working together. The right team skillset mix makes or breaks a project. Very often, the wrong skill on a task can bring a whole project down.
Projects should be self contained, and if possible all the skillsets required should be present on the team, or assigned for the duration of the project.
2)The project can be completely defined up front
This might be true given enough time and money, however in most cases software evolves over time. The understanding of a business problem at the beginning of a project is often changed by the time the solution appears. This is true of almost any invention - look at bicycles, for example..but in software it happens over the course of its development.
Iteration, and continuous refinement will happen, and should be supported by the management model for projects.
3)Technical people are fundamentally lazy
I sometimes believe that nontechnical managers really believe this, based on the way that project schedules are negotiated. There is never a willingness to consider that maybe the people who have the most direct involvement in writing and testing code are the people in the best position to understand what a given project takes. The fact that a non or semi technical manager has an understanding of the design and implementation does not immediately translate into a true ability to assess the overall difficulty. I have never been in a project schedule review meeting where a non technical manager accepted my schedule. Thus, by long indoctrination, I always pad my schedule.
If anything, in my experience what actually happens is that projects which developers find interesting or believe will be used are underestimated..projects which the reverse are overestimated. Heaven help you if you are a lead and have a boring but mission critical project to get done.
The most important thing you can do to get high performance is to identify work which is truly meaningful to the business and the users it serves, and to keep developers engaged on it in areas that they are good at and if possible mostly interested in.
4) Having QA as part of a development team is letting the fox watch the chickens.
This is one of my favorites, because the underlying assumption is that developers like to ship crappy code. Good developers HATE defects. I have rarely met a developer who, through laziness or a general lack of interest was content to consistently ship defective code. I don't believe developers who operate this way last very long, anywhere. In my experience, most developers are very concerned about testing, and have a deep desire to ship solid code that works and is easy to operate. What they need is help in getting there.
An external QA organization isn't that help..organizationally, its a setup for non stop conflict. Metrics get developed which are used against development and an excuse culture sets in. QA cannot be efficient unless it is staffed by at lease junior caliber developers who can effectively automate tests. Effective automation starts at unit testing and code coverage, so in essence QA starts in development and grows outward as components are integrated. In short, the fox and the chickens are on the same team and likely have very similar technical skillsets in an effectively managed development organization.
Build a product team around developers and testers working together, consistently, around the same code base over time.
5) Putting high pressure on target dates and development managers is what makes projects ship
Or "the beatings will continue".....this is perhaps the worst assumption. You can rarely get good quality work output during the bataan death march.
A business manager can ALWAYS get project schedule concessions through the whole first half of a project from a development manager - through a variety of bullying techniques including -
"If thats the date the project will be cancelled" - it never is...
"Your job is on the line for delivery" - it always is...
"If you can't do this, I'll find someone who can" - possibly, but you'll treat him or her the same way, and nobody is superman
Or my favorite - You gave me an answer i don't like, so I will poll your whole team looking for someone willing to undercut you.
Or last, thats the date, and we'll work the team continuously including weekends to hit it. - never really works.
This approach trains development managers in a technique I refer to as "incremental dissapointment". At the start of planning, a development manager is asked to assess the timeframe for a project. If hes dumb enough to just provide one which is realistic, the bullying will commence.
If hes really dumb, or just starting out in his or her career, he'll hold firm.....in which case he has created an opportunity for a third party consulting firm to quote a better date, or for someone else to lead the project. The smart move is to compromise on a date which the business manager will accept, with conditions that the business owns and will completely undersize (requirements/design review) in terms of time.
This all sounds horribly cynical, but it is a survival model for dealing with dysfunctional business management..remember, the starting assumption coming in is that you and your team are lazy, so you have to be "motivated" properly.
SO my advice to non technical leadership. Trust your technical leadership as a partner..if you don't, find a new partner.
These are just a few of my favorites..next post, I'll be focusing a whole entry on "why do we need developers once the code is written?"
-- Post From My iPhone, typos included
Subscribe to:
Posts (Atom)