There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

27 Answers
27

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.

+1 Dealing with this BIG TIME right now.
–
MetalMikesterNov 17 '10 at 12:57

4

If the time taken to fix is measurable in dollars, e.g. bug fix a shares trading system, then the management decision will lean towards reduced cost. I have found that proposing to "patch it up now to keep it running while we determine the correct fix to make sure this never happens again" satisfies the cost-driven urgency and also gets the right result, but you have to fight for this sometimes.
–
JBRWilkinsonNov 17 '10 at 14:25

8

We've got code all over with comments like "This is a hack, replace after the demo" that's been in the base for going on 3 to 5 years now. No one even remembers that it was done at this point, so no one finds it until someone (me) is fixing bugs and runs across it. Needless to say, this object lesson has taught me very well to do it right the first time if I'm in any way able to do so.
–
CodexArcanumNov 17 '10 at 20:34

21

And honestly, I'm continuously shocked by the number of times it doesn't even save short-run time!
–
PeterAllenWebbNov 17 '10 at 23:35

5

@Jorg - Huh? "Technical debt and design debt are synonymous, neologistic metaphors referring to the eventual consequences of slapdash software architecture and hasty software development." en.wikipedia.org/wiki/Technical_debt This is precisely what I'm referring to. A more specific title would perhaps have been "Incurring Technical Debt Without Intent to Repay It", but, many people in this situation tell themselves they actually do intend to repay (but don't), and I wanted a punchy title to put in bold text at the top. "Technical Debt" seemed to be a good enough summary.
–
InaimathiNov 20 '10 at 16:13

This one at least seems to have a basis in reality; keep in mind that non-technical people can't tell who the great developers are (so they're very likely to just pay twice as much to a random, consulting idiot than to an actual superstar).
–
InaimathiNov 17 '10 at 12:22

The 10x or 100x programmers are such insanely incredible value for money; they only get paid 1.5 maybe 2x. As Michael Lopp (Rands in Repose) says, if you only hire one of these in your whole career, it's a net win.
–
Tim WilliscroftNov 18 '10 at 0:27

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.

Just because it can be, doesn't mean it should be. A basic CMS, well yeah why reinvent the wheel. But when you start talking about large scale systems and modelling complex business processes - why try and fit a round peg in a square hole ? Especially if you have existing developers and skills in house.
–
NimChimpskyNov 17 '10 at 12:19

9

@NimChimpsky - I think there are valid examples of both. I've certainly seen people break their business processes and lose advantages they had by trying to fit them to off the shelf software, but I've also seen developers suffering from "not invented here" syndrome code things that they could have just downloaded because it was more interesting for them.
–
Jon HopkinsNov 17 '10 at 12:23

3

@NimChimpsky If the spec requires a bespoke development, then that is fine - it keeps us in jobs :) The problem comes when people don't first check whether there is something already developed that fits the bill and dive straight into development. A little research can go a long way!
–
Dan DiploNov 17 '10 at 12:26

6

Why reinvent the wheel? Because you're a wheel engineer. Or because your wheel is better than the next guy's wheel. Or because the wheel doesn't fit. See: mostlymaths.net/2010/03/…
–
DerekNov 18 '10 at 0:03

2

Where I work nearly everything could be bought OTS - and nearly everything is re-invented in-house because according to our Fearless Leaders (tm) "our environment is so complex that nothing on the market could possibly handle it". Pfeh! But what the hey - it pays the bills. We got told yesterday that a major component of our software is going to be re-written next year - WITH A GRAPHICAL INTERFACE! Ooooooh-aaaaaaah! I'm all a-twitter... (<pheh!>)
–
Bob JarvisNov 19 '10 at 2:55

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.

+1. Not providing good equipment for your employees has "bound to fail" written all over it.
–
Terence PonceNov 17 '10 at 15:07

3

+1. But note the following: in many companies, hardware budgets fall under infrastructure and kept separate from development budgets. The infrastructure manager isn't going to take a hit against his budget to help alleviate the development manager's budget. I've seen this nasty politic play out several times.
–
unsquaredNov 17 '10 at 18:59

3

How about bad equipment for ALL programmers? My ex-employer paid us Silicon Valley wages to write code on desktops that had been mediocre five years before. Because of blown deadlines, they laid off half the staff a year ago, and most of the rest in July - but boy, did they save money on equipment!
–
Bob MurphyNov 17 '10 at 20:08

3

When the hardware is inadequate I make it a point to let management know, usually by doing useful work like clipping my toenails or reading the paper during long compiles. I get the old slow machine? Sure, no prob. Oh, you got a rush bug fix and I've got to do the build? Sure thing, Mr-Manager-bwana-sahib-dude - see ya in 90 minutes! (Once had a manager ask me what I did all day - I told him "Re-built the app. Four times". "IN EIGHT HOURS?!?" he cried. "No, 'course not", said I. "That took 10 hours". New machine showed up not long after... :-)
–
Bob JarvisNov 19 '10 at 2:50

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.

The smart people can do anything well fallacy.
–
Jon HopkinsNov 17 '10 at 15:33

3

I've done data entry, although I certainly wasn't going to lower my rates for it. They wanted somebody who'd be fast and accurate for some critical data entry, and they didn't mind paying at least triple data entry rates. Their choice.
–
David ThornleyNov 17 '10 at 17:39

1

I'd argue that it's the programmers job to test their code, but I'm not sure if that's what you were referring to.
–
Ben LakeyJun 18 '12 at 23:42

3

Programmers should test their own code, not to the exclusion of having dedicated testers who are professionals at breaking software.
–
JohnFxJun 18 '12 at 23:44

1

Agree about the technical writing, disagree about testing. Testing is a natural part of writing good software. Technical writing is just too much of a shift from coding. I find I need to change many gears to go from coding to technical writing and it feels like a poor use of my time.
–
Adam BrussOct 30 '12 at 16:40

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.

I wish I could've upvoted this more than once.
–
MAKNov 17 '10 at 20:08

1

Lets write a GUI library. Lets build a messaging toolkit. If you don't SELL the piece of software, it's only a part of a larger thing, for heavens sake just use someone else's implementation. Safety points for using an open source solution, you can always fix and support it if you have to. If you've got the money to buy solutions with source included do so, but beware the poor quality of commercial software components. Vendors rarely sell you the component twice so you may be disappointed once you own it ( I know I've worked places that have been bitten by this before)
–
Tim WilliscroftNov 18 '10 at 0:33

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.

+1. My experience with off-shoring is that it inevitably costs a good deal more money than it saves.
–
Adam CrosslandNov 17 '10 at 14:14

2

+1, but offshore can work if used correctly
–
user2567Nov 17 '10 at 21:38

2

+1. We seem to get different off-shore developers on each new project, meaning the on-shore developers spend most of their time teaching the new off-shore devs the business and technical domain model in addition to providing technical support. End of project and they're gone somewhere else and we start all over again with the next set of 'cheap' developers.
–
Chris KnightNov 17 '10 at 23:57

7

many teams just hire a dozen offshore and barely use them at all, just so they can get 4 onsite contractors. Wow.
–
poolieNov 18 '10 at 0:10

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.

+1. Also: the longer the feedback loop, the less you remember about the task. At the extreme, you need to re-acquaint yourself with the entire codebase all over again.
–
Arjen KruithofNov 17 '10 at 22:36

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.

That's pretty special. Compare and contrast with some of the merchant banks in London who had a subsidised Starbucks built in the building to eliminate the time it took to go out and get coffee.
–
Jon HopkinsNov 17 '10 at 13:43

47

I disagree that this is automatically a false economy - the 10 minutes of fresh air while walking outside to purchase the coffee will oxygenate the employee and improve their concentration and the (albeit limited) social interaction will reduce depression, especially in winter. Those employees who won't get coffee because it's not free, will likely go home on time, get more sleep and have better health due to reduced caffeine intake.
–
JBRWilkinsonNov 17 '10 at 14:18

6

-1, a 20 minute walk is perfect to free up your mind, and get a fresh perspective on the problem.
–
MalfistNov 17 '10 at 14:21

23

@Malfist: As I understood it, it wasn't just the 20 minute walk, but also the 15 minute wait to actually get the coffee that interrupted work. A 45 minute break at any point in the day is pretty much going to destroy productivity for well over an hour and a half. All to save 100 bucks a month on coffee.
–
EricBoersmaNov 17 '10 at 14:42

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.

Was facing exactly that issue once. Wrote a mail to one of our CEOs explicitely calculating that given a 5% increase in efficiency I would have saved an amount of money worth the monitor in about half a month relative to my net income. This calculation was pretty much ironclad ... but ... I guess you already know the end of the story :)
–
RaffaelSep 7 '11 at 8:26

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.

As a consultant, I've been there, done that, and got the t-shirt. (Only got $80/hour, though.) But hey, that's one reason I like hourly contracting. Unlike a salaried position, if a consulting client chooses to waste my time and I have to work extra to make up for it, that's more money in my pocket.
–
Bob MurphyNov 17 '10 at 22:45

2

No offense, but if I'm paying $150/hr for a consultant, he'd better have his own computer.
–
Steve EversNov 18 '10 at 16:41

8

@SnOrfus: That doesn't usually work in the corporate environment, where there is strict control of the PCs which are allowed on the domain. You have to provide them with hardware.
–
HardCodeNov 18 '10 at 22:04

1

@HardCode - Yea, I suppose. I can see the point now.
–
Steve EversNov 19 '10 at 5:42

3

@HardCode On a recent project, instead of adding us (contractors) to their internal corporate network, they quarantined us to our own DSL line. A dedicated DSL line for 3 developers @ $40 a month is chump change and it made it easy for us to push updates remotely without sending the IT staff into a panic. Plus, if the production PC running our code gets infected and crashes, it's automatically our fault since we're responsible for the security of our communications and personal laptops. Can you say win-win-win.
–
Evan PlaiceNov 19 '10 at 17:53

In grad school there was a saying that a few weeks in the lab can save you an hour of library time.
–
David ThornleyNov 17 '10 at 17:42

7

Yup. When I was taking an undergraduate lab class where we identified unknown chemicals, the prof told us "an hour in the library will save you four in the lab". I took him seriously, and it was hilarious to waltz into the lab for an hour a week and get nasty looks from the pre-meds who were spending twelve hours a week doing amine tests on compounds that clearly weren't amines. And when I taught the same lab several years later, I gave the students the same advice, and just as few actually took it.
–
Bob MurphyNov 17 '10 at 22:51

I've been on projects where they'd make us waste a week or two instead of buying, for example, a library for $300 with the work already done - and better (we're not "control developers" where I work.) Or pick some software tool "because it's made by "this or that" company" instead of looking if there are better alternatives, then make our life hell for years.
–
MetalMikesterNov 17 '10 at 12:59

"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.

+1. Oh God yes. This is currently happening on an epic scale on a major project where I work.
–
Bobby TablesNov 17 '10 at 20:14

3

I work with a bunch of project leaders, managers, etc, all of whom have their oh-so-wonderful project management certification (whatever the heck it's called) and NOT ONE OF THEM had heard of The Mythical Man-Month before I introduced them to it. Sheesh!
–
Bob JarvisNov 19 '10 at 3:01

2

I heard a great quote about this once: 9 women can't make a baby in a month
–
RichardFeb 16 '12 at 13:56

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.

I bet there are a bunch of examples of the opposite too.
–
Jon HopkinsNov 17 '10 at 11:52

12

To buy or develop comes down to the right people doing due diligence. Simple as that. Think before you act. (+1)
–
DevSoloNov 17 '10 at 12:24

3

@DevSolo : spot on. The build-or-buy decision should be backed by a cost-benefits analysis, rather than an emotive 'not invented here' or 'I love XXX's software' attitude.
–
JBRWilkinsonNov 17 '10 at 14:22

9

If you're going to make a blanket statement about build vs. buy, it should be: prefer to buy solutions to problems that aren't part of your company's core competency. It's not always the right answer, but it's a sensible default position, and about as reliable as a cliché can be. To say that buying off-the-shelf software is a false economy, though, isn't even a useful cliché.I feel your pain w.r.t. to 'E' solutions (which is supposed to mean 'Enterprise', but really means 'Expensive'). But the presence of bad options doesn't mean there aren't good ones out there.
–
evadeflowNov 17 '10 at 21:50

1

Counter examples: developing your own GUI toolkit. ( In the 200x's!) Writing your own messaging/RPC system. Hmm, these seem to be library components.. maybe this is a discriminating factor
–
Tim WilliscroftNov 18 '10 at 0:36

Erm, can this be considered "worst false economy"? Or probably you need to elaborate more...?
–
GanNov 18 '10 at 1:16

3

I'm not sure I completely agree with the example of source control, at the very least. Git was specifically engineered to solve open-source problems: Many developers, little central control, many branches, etc. The "enterprisey" software works under a different set of assumptions: The need to manage a variety of products across a business, security, workflow, etc.
–
PeterAllenWebbNov 18 '10 at 2:24

3

I'm a contributor to X11 and GNOME, and quite competent at using git and administering gitosis servers. Nonetheless, this summer I switched my consulting work from git to a personally-paid-for Perforce server because it does a lot of things automatically that you have to do manually with git. Since I get paid for delivering code and not screwing around with version control, using and paying for "crappy enterprisey version control" is far more cost-effective for than using git.
–
Bob MurphyNov 18 '10 at 5:36

Yeah. You might rephrase this as making the wrong choice. I'm not going to do anything to the 3-D PDF software on my own initiative as long as we're using the OS U3D package.
–
David ThornleyNov 19 '10 at 21:52

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.

+1: Just keep using C because "we have those skills and learning some new-fancy language like Python/Perl/PHP adds to much risk". Heard it more than once. Does that mean the team is too stupid to learn a new language?
–
S.LottNov 17 '10 at 21:15

1

@S.Lott Recruitment agents think you are!, but that's another story
–
burnt_handNov 17 '10 at 21:58

2

i.e. companies that stick with Java and C# and are too afraid to touch python or ruby because they're not "industry standard", which reminds me of: paulgraham.com/avg.html
–
hasenNov 18 '10 at 2:54

1

@hansen: The Paul Graham essay is partially what inspired me to write this post. My other inspiration was my work developing libraries (including the standard library) for the D programming language.
–
dsimchaNov 18 '10 at 3:16

I agree that there are bad managers, but "the project would do much better without the upper management decisions"? Generally these are the people who are sponsoring the project. This sounds to me like a little bit like the developers I've met who think understanding the technology is more important than understanding the business and forget who the actual customer is.
–
Jon HopkinsNov 17 '10 at 14:11

2

@Jon Hopkins With upper management I don’t refer the customer. The point is "bad project managers" are those who does mistakes after mistakes, and goes against a group of people. Who do you think decide "Just do it quickly, we'll refactor later". Read the answer with highest rate!
–
Amir RezaeiNov 17 '10 at 14:19

1

@Bernard - time and cost are measureable. Quality? Not so much. Sad but IMO true...
–
Bob JarvisNov 19 '10 at 3:03

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).

@Andrew Grimm - The "only" thing that ISO 9001 guarantees is consistent, repeatable quality. It does not guarantee "high" quality. However, if an ISO 9001 qualification is what's required in the market space the company wants to be in, then it's required.
–
VatineNov 17 '10 at 12:56

1

@Vatine: What ISO 9001 guarantees is consistent, repeatable process. In some fields, where consistent processes yield consistent quality, that's important. It doesn't guarantee high quality, but if a customer sees something you've done well and knows that you're ISO 9001-certified, they'll be confident of similar quality.
–
David ThornleyNov 17 '10 at 17:42

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!

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.

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"

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).