Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment They should NOT be treated differently (Score 1) 716 716

The developer agreed to deliver software that did X. They did not do so. Thus, they are in violation of their agreement and must make amends. Simple as that.

As to why things are often not done this way, in my experience, it is because developers desperately want the software business to be different. They don't want the traditional rules of industry to apply to them. They want to be special snowflakes, and management is letting them.

Comment Perhaps people are growing up ... (Score 1) 503 503

... and realizing that dicking around with what is ultimately a tool is an impediment to getting useful work done. That's the realization I had. I used to delight in building my own computers from parts ordered online, rebuilding kernels to be lean and mean, compiling all software from source, tweaking things endlessly, etc. But somewhere along the line I became more interested in what I could do with the machine rather than the machine itself. Now I just want to plug something in and go.

Comment Study philosophy (Score 2) 361 361

Being good at general scientific reasoning requires a firm understanding of scientific philosophy. This is not a subject many people encounter directly unless they're on a scientific track at a university. Very few, if any, will pick it up just from engaging in scientific activity.

Comment Yes, anyone can learn, but ... (Score 1) 767 767

Anyone can learn to program, just like anyone can learn to build a house or drive a car or bake a cake. But not everyone can learn to do these things well. The lower an industry's barrier-to-entry, the more crap people one will find working in it. Just look at the software business.

Comment Re:Requirements do change (Score 1) 491 491

Your entire post reeks of bad management. Anyone who initiates a project without basic boundaries is a moron. Anyone who cannot decompose tasks is unqualified to lead. Anyone who allows things to go off on tangents should be fired. It's that simple.

Comment Re:Developer rebellion? (Score 2) 491 491

One of the assumptions in Agile is that at almost any point you could go back and recode a significant amount of the work once you realize that you've been going down the wrong design path. Sounds nice on paper but in reality I doubt that ever happens.

Happens in my company all the time, but it requires competent management and lots of discipline. The software design has to support such changes, as does the work environment. If you've got a jumble of spaghetti and a boss who just wants it done, you've got management problems. No system is going to be very effective.

Comment Re:I fix the bugs (Score 0) 221 221

Agreed 100%. If you can't stop what you're doing and fix a bug in a few minutes, you've got management issues. The only exception to this that I've encountered are the rare situations where I'm using a system and nowhere near my development environment. In those cases I use whatever communication tool seems appropriate: email to myself, voicemail to myself, note scribbled on paper, etc.

This concept works in team projects as well. If you need a tracker, you have bigger problems than software defects.

Comment Re:Suprising that no one has sued. (Score 0) 327 327

This is exactly it. Everything I ever saw from Apple on this subject said their products were immune to the large volume of PC viruses out there, which is completely and totally true. They probably changed their tune in order to avoid a waste-of-time lawsuit from people who can't read.

Comment Half-Assed Society (Score 1) 211 211

Our society indeed has a problem with accepting half-assed work. In my experience, employees and managers alike just want to be able to say something is done regardless of whether or not it really is. Few seem to show concern for doing a good job, and those who do are ridiculed for it.

% APL is a natural extension of assembler language programming; ...and is best for educational purposes. -- A. Perlis