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