Costly Tool Addiction
I know we all want to use pre-fabricated solutions and components, and I agree that it can be a very good thing. But we have to look at the lifecycle costs of our tools and not assume that having a tool is always better than not having one.
We find that a project often has a budget that it can use to improve software process, and it seems to make sense that that money can be spent on tooling, but often the best use of that money is outfitting the team with the hardware and training they really need.
A few ways that expensive tools increase the cost per seat for an organization of windows machines:
Licenses
a initial client licenses
b initial server licenses
c recurring licensing fees
d acquisition cycle (time costs)
e monitoring license compliance (gets more important these days, yes?)
f cost of accepting new versions during a development cycle
Hardware Capability
a RAM
b CPU
c DASD
d Network bandwidth and balancing
e Upgrades to servers (downtime)
f Upgrades to developers (downtime)
Setup time
a Inventory the hardware
b Installing the operating system
c Install each one of the software tools (reboot reboot reboot)
d Inventory the licensing
e Apply the upgrades (downtime for servers, developers)
Raw number of machines
a Official, "golden" system (deployment/demo systems)
b Regularly scheduled integration build/test machines (cruise control, cron, whatever)
c Lab work (floating machines to test build changes, new frameworks, new component version)
d Developer machines
The ability to add machines is important. It's good to have a server where you can test code in isolation, or stage a release, or do integration testing away from the development environment and the production environment. It's good to do changes to the build system on the machine that has to do the builds, for obvious reasons. You need "offline" engineering, and "online" production.
Sometimes adding lab machines (for working on build, test, etc) is NOT done because prior issues have made the cost per machine too prohibitive. Sometimes there wasn't insight before the whole budget was blown on expensive tools instead of holding reserve for what should be the miniscule investment of a PC.
Programmers working on business applications should be able to work on a sub-1K-priced machine nowadays. Often we're better off having more machines than if each of us has "more machine." Clearly, though, we each need "enough horses" to develop and test the system in isolation from other developer pairs.
Not everyone needs a server room full of devices, but even small teams may need two or three servers for isolated testing, especially for long-running tests or short technology spikes.
If free tools will suffice (and often they can) then most of the costs listed above can be mitigated or eliminated. There are some really good ones out there, from language compiler and interpreters to frameworks, to authoring tools of various types. Clearly the open source has produced some of the best software the world has ever seen from browsers and web servers to programming editors, databases, and lord-knows-what. The biggest problem with free tools (IMHO) is picking the one that's right for your team. You may end up changing databases and changing editors or frameworks once or more. This is another good reason to try new things with separate hardware and in isolation before going mainstream. It also argues in favor of certain architectural components like object-relational mapping tools (to reduce the cost of database migration).
I'm not saying that you can't use restricted (ie: non-free) tools, but rather that you have to keep the cost of expensive tools in mind, because you won't pay only once. You need to make sure it provides enough value to be worth the cost. If it becomes too expensive to add another $1200.00 PC to your development team because of licensing and administrative overhead, let me suggest that you may have overpurchased already.
After all, we're supposed to "never be blocked" these days. If the licensing is a block, maybe we can find legal ways to use products that don't impede our progress?
!commentForm
Reasonable thought. Isolation, expansion and so forth. The reality seems to be defined by vendors very often. Large, slow bureaucratic company environments look for ways to get quicker and so forth. Poof and someone now believes the answer to all their problems is the purchase of an end-to-end suite of tools with templates and processes - when in fact, the issue is they don't manage their work queue well and constrain their employees from free thought. While some companies decry open source due to indemnification or security reasons, I'm not convinced most tools purchased are necessary. Many times, we simply don't know how to use what we already have very well - including teams, tools, work queueing and anti-process.
Cem Kaner once said that software has the "cat food problem." Why is cat food (software) so bad? Because the people who buy it aren't the ones who consume it.
I think that ultimately the answer is letting teams and developers buy or acquire their own tools. The further you are from the work, the less likely you can make an appropriate choice.
I think that ultimately the answer is letting teams and developers buy or acquire their own tools. The further you are from the work, the less likely you can make an appropriate choice.
Michael,
That seems on the mark. Countless meetings I've seen (experienced or received) whereby the people with the purse strings negotiate deals absent the people who actually do the work. Yet another argument supporting self-directed teams. Speaks to Schwaber's illustration of the chickens and the pigs as well.
That seems on the mark. Countless meetings I've seen (experienced or received) whereby the people with the purse strings negotiate deals absent the people who actually do the work. Yet another argument supporting self-directed teams. Speaks to Schwaber's illustration of the chickens and the pigs as well.
Add Child Page to ExpensiveTools