The Right Tool for the Job – Part 1

I’ve become increasingly discouraged by software companies not providing the right tools for software engineers so that they can get their projects done and meet ever shrinking deadlines. This is even more important with the emergence of new development methodologies such as SCRUM and Agile. For some reason, most executives who run software companies do not understand how important this is to the bottom line. All they see is the cost on a spreadsheet and not the long term cost of labor, lost revenue and time to market. I have never understood why they can’t see these facts when it’s so simple for me.

Let me give you an example that you can take to management so that they might understand.  Let’s say you are having a remodeling job done for your house and each person working on it is getting paid $100 an hour. Now, would you want these workers using hammers or nail guns?  I would assume you would choose nail guns, which allows the workers to complete the work much faster and also delivers much more force on the nail. The next question is would you want them using the latest, fastest nail gun available or one that is old, constantly breaks down and in the end wastes many hours of work for each person a week? I think the choice is obvious.

For some reason, in the software world, since software engineers are glued to a computer screen all day and creating something that is virtual which some consider not tangible, something you cannot touch… it is different.  Therefor due to the inadequate tools provided to software engineers when we can’t make deadlines, customers are upset and even dropping the product/ service, competitors are beating the company in the marketplace. We tell management about these issues and they do nothing, it just purely amazes me. Sometimes I wonder how they got their job or if they even know how to run a software company/ department.

Real Examples

Let me give some real examples that I have seen. Some of our programmers are currently working remotely. I recently found out they are using 5+ year old machines that have a Pentium 4 3.4GHz processors with 3G of ram (give or take on the specifications). I am not joking here!

Here is another example I hope bean counters would understand… the last time we ordered new computers for some of the developers, I designed them to properly run our development environments on a virtual machine (to easily switch to different version of source code for development and testing). My direct manager, his manger and the CTO for our department approved this computer design from our budget. When it got down to the IS, they lowered our memory and disk drive specifications to save around $300 for each machine.  Because of the slower machines, I have estimated that the company is now loosing at least $6,500 of the bottom line per developer in the company. Does this make sense at all to anyone?

This reminds me of something that happened a long time ago, early in my programming career. My boss brought around a group a Japanese business men to show off the development department (don’t remember why). One of them asked if all the developers are using the latest fastest computers available… he said yes. I had to bite my tongue because that of course was not true.

More will be discussed in future posts on how hardware and software, the tools for software developers, should be made available to help make product release deadlines.

Please feel free to comment on this post below.

Please read The Right Tool for the Job – Part 2

3 thoughts on “The Right Tool for the Job – Part 1

  1. I have a simple plan. I think it’s also a smart plan for a company that wants to make good use of their resources and satisfy their customers. One side-effect is that the developers end up with the fastest possible machines; but that’s a side effect, not the goal.

    You start with a common observation: most people buy all the software they’re ever going to use on the day they buy their computer. There are some exceptions (gamers being a HUGE exception). But home users and a large chunk of office users will generally stick with what comes with the machine or what they install in the first week or so. So if that’s where your most eager purchasers will be, that’s the group you want to target. That’s your sweet spot. You want to sell to others as well, of course, but they’re the ones who are most open to buying software.

    And most people buying machines (again, gamers being a huge exception) don’t max out their machine. They get a good machine, maybe, but not the best possible.

    Meanwhile, we know that software takes time to build properly.

    If you put those three observations together — you want to target people who are getting a new machine, that new machine won’t be top of the line, and you need time to target — then it leads to this plan.

    1. Every year, buy your devs the most powerful, most expensive machines you reasonably can. These are better than your customers are buying TODAY; but that’s the machine you use to build the software your customers will buy NEXT YEAR. So your devs are developing on a machine that is comparable to what your “sweet spot” customers will be using when your software finally ships. And for that year, your devs are working as fast as they possibly can. If something slows them down, it won’t be the hardware. (It’ll probably be meetings…)

    2. When the devs get their new machines, give their old machines to QA. That means QA will be testing today’s code on last year’s machines, which are still pretty decent, and will roughly match what TODAY’s customers are using.

    3. When the testers get the old dev machines, give their old QA machines to the doc writers. Yes, these will be a little behind the curve, but not drastically so. They should run all of the code from the last year or so well enough for the docs people to document that code.

    4. When docs gets the old QA machines, give their old docs machines to admin. OK, these machines are three years old, but that should be fast enough and powerful enough to run the latest Office, browser, email, etc.

    5. When the admins get the old docs machines, give their old admin machines BACK to QA. These are four-year-old machines. They should be a good test case for how your code runs on older machines for customers who are slow to upgrade but still want to buy your new code.

    6. When QA gets the old admin machines, give their really old machines to charity. They’ll be five years old, you’ll have five good years of use out of them, and I’ve known charities running on MUCH older hardware than that. I don’t know tax accounting and depreciation, but maybe you can even claim a deduction for the donation.

    It makes sense to me. But instead, we get to run on old, tired machines running an operating system designed in the last millenium…

Comments are closed.