What are the worst false economies in software development?

Question

What are the worst false economies (that is ways of saving money that ultimately cost more than they save) prevalent in the software industry and how do you combat them?

Answer 1

Technical Debt

ie "Just do it quickly, we'll refactor later". Firstly because I have yet to see someone engaging in this behaviour actually refactor later. Secondly because doing things the quick way, instead of the good way makes it harder to add future features or resolve future bugs so you end up losing time in the long run.

Sadly, many still think it saves developer cycles to have them do something fast. I guess it's possible, but I have yet to see it in practice.

Answer 2

Hiring 2 cheap developers instead of 1 really great. (for the same price)

Answer 3

My example would be the complete opposite of NimChimpsky's example, namely:

Trying to develop in-house something that can be bought off-the-shelf.

Normally this comes about due to a failure to actually check the market-place to see if something already exists that will solve the problem. This can be compounded by developers who like to "dive in" coding before doing any research and by project managers who fail to factor in that time = money.

One of the most common examples I've seen in my field, web development, are companies trying to develop and in-house CMS system. These invariably start off small, but soon get bloated and out-of-control as features are bolted on, whilst all the time there are plenty of free products and frameworks out-there that would be much better suited.

Answer 4

No dedicated resources for project management

I've experienced several times when a few programmers were contracted, and someone who already has a demanding day-job should have managed the project, but in fact was too busy with other tasks so the project never really gained momentum. The programmers made "prototypes" and stuff, but without a lead, much of it was running in circles to look busy.

Bad equipment for new programmers

I've once experienced a company where the policy was "new programmers have to work on an really old PC with a small screen until they prove they are worthy". No surprise that such a policy caused a negative selection that drove off good people who always have the choice to work in a more sane environment.

Answer 5

We can save money by having the programmers double as testers/technical writers

If you are paying programmer salaries for tester/technical writer work, then you are wasting money and likely getting lower quality work than someone who has dedicated their career to that task. Also, when a programmer is up against a tight deadline testing and documentation are very likely to get dropped or done half-ass to meet it.

BTW: Developers are ALWAYS up against a tight deadline.

Answer 6

Researching / Reading / Writing code not related to the product development is a waste of resource.

Some programmers and even managers believe in that. Normally, they just do programming based on the knowledge in their heads, and do research and look for answers when they face problems. They don't continuously improve their knowledge proactively. My opinion, we should always keep ourselves up to date, and the knowledge we gathered would be useful to us in solving existing and future problems. Of course, you must allocate your time wisely to do so.

This is also similar to Dan's answer. Some managers just want the developers to quickly dive in and develop the product according to requirements without researching on existing products in the market.

Answer 7

In many cases offshoring costs more money. In my company it's very hard to get new employee slots, we are pushed heavily to outsource. Its also hard to get on-site contractors; there is ratio of 3:1 offshore to onshore they are supposed to maintain. Consequently, many teams just hire a dozen offshore and barely use them at all, just so they can get 4 onsite contractors.

Answer 8

Long feedback loops!

It happens to everybody: you build something that you think is awesome, and it turns out you were wrong. That isn't the problem. The problem is how long you spend building before finding out that you should stop.

At the high level, you see this problem with long release cycles. If you build for a year without feedback, you're gambling the whole year. The more often you release, the smaller your gambles, and the better you get at gambling.

But it also happens at the lowest levels. As a developer, I really like frequent code reviews (or, better, pair programming) because it limits the amount of time I can continue doing something dumb before somebody says, "Hey, there's a simpler way!" For the same reason, I like my unit tests to run quickly and frequently, so I can catch and kill bugs before they grow.

Once you start noticing the importance of short feedback loops, you'll see it everywhere. E.g., the military notion of the OODA loop.

Answer 9

Not my own anecdote, but I did once hear of a shop which stopped providing free coffee to its developers, telling them instead that any time they wanted to get coffee, they were free to walk to the nearest coffee shop (something like a ten minute trip each way) and purchase some.

Pretty much the definition of false economy.

Answer 10

Providing single-screen workstations because a second monitor is too expensive. Even if it only saves you an hour of work each year, an second screen is still a good investment. I know for sure that mine has saved me many, many hours of work.

A Multi-monitor setup can make almost any task more efficient, not only development tasks. Three monitors is even better than two, but the effect becomes less pronounced with every extra screen.

Multi-monitor setups:

• decrease window switching overhead
• allow you to keep an eye on stuff running in the background (mail, compilation, etc.).
• give you a feeling of freedom. It's like being in an atrium vs. being in a broom closet.
• etc...

Answer 11

Cheapest hardware given to a consultant when the consultant cost more than 150$/hour.

Putting it in perspective a better hardware may at least make the job 30min more effective per day. That would give 30min * 20 days of work per month=600min/month =10hours/month > more that 1 day job = 10 hours*150$/hour = 1500$

Now wouldn't a consultant work more efficient if he/she had a 1500$ computer? Would it make the consultant less irritated?

Now the problem seems to be that there two budgets, one for the consultant and one for the PC hardware.

Answer 12

Months of work save days of planning

(Not investing enough time into planning)

Answer 13

Most prevalent I suspect is managers simply not providing developers with the tools they need to do their job efficiently.

Basically, point 9 on the Joel Test.

Answer 14

"Throw (enough) bodies at the problem" may still be used in some places, unfortunately. Brook's Law does counter this from The Mythical Man-Month, though some require experience to learn this lesson. Generally this isn't something within my power to stop as management may believe the false statement about adding people and not having to pay a price for it.

Answer 15

Everyday meetings:

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  

Answer 16

Buying off the shelf software instead of developing it internally.

I have experience of entreprise scale management systems, focussed on both HR and Biological Laboratories.

An off the shelf solution cost £50-100k and needed further development and customisation to meet the business requirements.

The internally developed solution took (<6) months to develop, with other projects being worked on in parallel, and utilized an already employed developer.

I went from the public sector where we had an internally developed LIMS (lab information management system) up and running, to a large international pharmaceutical where the implemention of an off the shelf solution had taken over a year and was nowhere complete.

(6 months of an already hired developer working on other projects in parallel. So ~10k. And that doesn't include the support costs associated with the off shelf solution). The major point is that the internally developed system was actually being used! So you then have the added cost benefit associated with that, which I cannot calculate.

I'd agree for basic websites etc, why bother developing your own. But for any large complex systems and if you already have in house skills, I'd build it myself.

Answer 17

Buying expensive off-the-shelve products when the open source alternatives are better and free.

How many companies use git? How many companies use some crappy enterprisey version control?

Answer 18

Using "simple" languages without much expressiveness

Yeah, it makes it easier to find programmers to maintain the code, but it makes it harder to find good programmers who don't just learn the latest buzzword that will get them hired. Yeah, it makes individual bits code easier to understand, but it also makes it about as rigid as a 2x4 and increases the volume of code that needs to be understood. Yeah, it's backed by a huge corporation, but said huge corporation innovates slowly and bureaucratically.

Answer 19

Bad project managers/team lead.

Since one incompetent person’s have the power to ruin the work of a group of people. In the end, the project would do much better without upper management(project/team lead) decisions.

Dose the "Just do it quickly, we'll refactor later" decides.

Answer 20

Missing user requirements

An important and difficult step of designing a software product is determining what the customer actually wants it to do.

Believe it or not sometimes this part is missing or is outdated. What it comes to cost is that one creates functionalities that the end user never asked for.

Answer 21

Productivity is worth more than creativity

Creativity is difficult to measure in general, and most often impossible to even observe, never mind measure, when it comes to software development. Productivity, on the other hand, can be measure (often poorly), and can be observed.

As a result, developers which can (write more lines of code|write code faster|recite technobabble faster in response to questions|are more visibly productive) tend to be valued more than those which (use fewer lines of code to solve same problem|take longer to write code, but produce a more reliable product|understand the subject matter well enough to answer questions in plain, easy to understand, English|creatively solve problems).

Answer 22

All below can be bad when used or not used inappropriately

• external vs inhouse software

• ISO 9001 compliance (economy - a mitigation of a MSS loss risk if product quality drops)

• development/QA outsourcing

• development/build/release/support procedures

Answer 23

Having too many non-billable delivery managers.

Couple of years ago, in our company we had several big budget projects going on and recruitment was at peak. At that time our company hired too many delivery managers (Many of them were non IT!) and very few coders/testers. Manager to Programmer ratio was literally 1:2. Later, after completion of those projects, we had a situation where we had many of these managers (some of them were real slackers) sitting on bench doing nothing. We had one appraisal cycle where everyone got little/no raise (Even us hardworking programmers, sigh) so that company don't have to lay anyone off! Fortunately, company realized this situation and did the RIGHTSIZING in the first quarter this year!

Answer 24

Optimization before profiling (aka premature optimization).

Too many times I've seen someone reach for a clever solution which needlessly complicates maintenance and readability on the grounds that it's faster. Naturally, the code hasn't been bench marked (not even with micro-benchmarks), so it quickly becomes "faster based on the more persuasive argument" over a section of code which most likely didn't impact the overall performance of the entire application by much.

As such, it is a very false economy, and the kind of false economy that occasionally entangles even the seasoned pros.

Answer 25

Limited or no internet access

Because obviously your employees will use use the internet to play facebook games not too research answers to technical questions on Stackoverflow.

In reality of course the internet is a huge productivity boost, and while it may be appropriate to use some sort of site filter for genuinely dodgy sites there is something wrong if it is blocking the visual studio readme file or blocking telford local goverment pages for reason "sex tourism"

Answer 26

Making your developers use a 15 inch monitor and low spec PC as it is the corporate standard.

Reasonable sized monitors are cheap, quick to install and make the programmers more productive as well as making your programmers think you care about them.

Answer 27

Too many Bachelors of Business Administration (or the like), hierarchically organized, that try to apply what they think modern management is about: Bothering people with "KPI"s, "SLA"s and what not, requiring "reports" (without, of course, caring about the infrastructure to generate them), so that programmers waste their days filling in fancy EXCEL sheets, Q4 reports and what not and copy from one great new management tool and paste into another one (it seems to be the rule that these tools are never inegrated nor integratable with each other), and attend meetings where the reports and figures are presented (and everybody is made feeling guilty about having failed to fullfil this or that KPI).