Tag Info

Hot answers tagged

172

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


81

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


72

In 16 years I've never actually found a workable metric of the sort you're looking for. Essentially to be useful anything would need to be measurable, representative and ungameable (that is the system can't be played by clever developers). There are simply too many variables within software development to make it measurable as piece work in this way. The ...


69

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


66

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


59

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


55

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


49

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


46

Yes, it is irrelevant. Computers are tireless, near-perfect execution engines working at speeds totally un-comparable to brains. While there is a measurable amount of time that a function call adds to the execution time of a program, this is as nothing compared to the additional time needed by the brain of the next person involved with the code when they ...


43

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


43

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.


37

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


35

Months of work save days of planning (Not investing enough time into planning)


34

Indentation One-liners like that do introduce a bit of a hazard in terms of keeping the brackets correctly matched. Most decent editors will match the brackets visually to help, but it is easier to expand it. (function($) { $('#element[input="file"]').hover(function() { $(this).fadeOut(); }, function() { $(this).fadeIn(); }); ...


34

Maybe because productivity is something hard to measure, whereas hours of being apparently working are not, so they often choose the easy way.


34

I lead a small team and I can tell you now that I will NEVER allow it in my workplace. Here's why: It sucks if you are NOT a developer. The last thing my QA and Admin people want to see is people having fun while they are working. They don't care if it might make sense, it just pisses them off and I'll have to deal with department heads that have ...


34

Microsoft has done some very interesting research in this direction, if you look into Singularity: http://research.microsoft.com/en-us/projects/singularity/ Also, Mothy Roscoe et al have been working on Barrelfish which uses the Eclipse constraint programming language as an OS service to sort out all kinds of OS management and resource allocation problems: ...


32

Run your tests in a virtual machine with limited memory and only one core. The old machines people still may have now are mostly Pentium 4 era things. That's not that unrealistic - I'm using one myself right now. Single core performance on many current PCs normally isn't that much better, and can be worse. RAM performance is more important than CPU ...


31

Metrics work best in factories, and programmers don't work on an assembly line. I completely understand the desire to measure productivity. But would you use the same metric for a family doctor and a heart surgeon? How about for Michelangelo painting the Sistine Chapel, and some guy in Mexico cranking out black velvet Elvis paintings? Louis de Broglie ...


31

In my experience, the simplest answer is that [ several, many, most ] of your coworkers don't share your passion for development. They're just there for the paycheck. If a pool table or Xbox was available, the extra policies and monitoring to prevent abuse of these perks would cost more than the productivity that someone like you might gain. That said, ...


31

A lot depends on where you put the division between low-level and high-level languages. For example, different people tend to put a language like C++ on different sides of that divide. Regarding your questions: I don't believe there is such a difference between low-level and high-level languages, but more a difference between interpreted languages and ...


29

Research Material There are a few but not all are current or applying exclusively to our field: Work-at-home and the quality of working life Substitution between working at home and out-of-home: The role of ICT and commuting costs The perils of working at home: IRB “mission creep” as context and content for an ethnography of disciplinary knowledges ...


29

Are there any practical considerations that I am overlooking which making binary search better than linear search? Yes - you have to do the O(n log n) sorting only once, and then you can do the O(log n) binary search as often as you want, whereas linear search is O(n) every time. Of course, this is only an advantage if you actually do multiple ...


27

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.


24

Your questions has the answer in it. Adding man-power to a project that is running late, only makes it worse because the communication overhead increases in a non-linear way. It's already been studied. Read "The Mythical Man-Month".


23

I used to run an IT department for a small business in Florida, where hurricane strikes were a very real threat. After our first very-near miss, we started getting a lot of inquires from our customers about our disaster preparedness plans. So, we started looking at telecommuting as an integral part of our company's disaster preparedness. In the event of a ...


22

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


22

It depends. In the glacially-slow world that is Web programming, where everything happens at human speeds, method-heavy programming, where the cost of the method call is comparable to or exceeds the cost of the processing done by the method, probably doesn't matter. In the world of embedded systems programming and interrupt handlers for high-rate ...



Only top voted, non community-wiki answers of a minimum length are eligible