Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There is a long and ignoble tradition in the software industry of vendors who prey on the ignorance of managers and executives to sell expensive tools that allegedly eliminate or reduce the need for programming. Executives fall for it because they know that programming is hard and expensive but not why it is. The prospect of a tool that will eliminate their dependency on programmers is very seductive. What programmers produce is usually late and over budget and works like crap. They themselves tend to be weird, geeky, and erratic. Who wouldn't want to be rid of them? Meanwhile, the vendors with the magic programmer-replacement tool are wearing nice suits and know all about the problem. They are full of stories about how great it would be if business people - normal people - could "just" make the computer do what it should. "Defining business processes" shouldn't have to require programming, after all. Normal people know about business processes.

This is a sales job made in heaven. At no point in the process - the sales process - is it required for the tool to actually work. All they need is enough of a demo to convince the stakeholders - who already want to believe - that it will take away their pain.

At this point the well-chosen trivial visual example inevitably makes its triumphant appearance. Who can look at the diagram the post cited (http://secretgeek.net/image/NXTCode_small.jpg) and take anything associated with it seriously? Yet people do. Important people.

In this dysfunctional dynamic, a new crop of tools that will work "this time" makes a predictable appearance every 5-10 years. One reason this persists is that it's in no one's interest to publicize the failures. When such tools are purchased, rolled out, forced on organizations, and result in an even greater clusterf--k than what was there before, who's going to say so out loud? Obviously neither the vendors nor the executives. And only programmers listen to programmers.



There is a long and ignoble tradition in the software industry of programmers who prey on the ignorance of managers and executives to convince them in uselessness of productivity enhancing technologies so that the programmers can enjoy building their own productivity enhancing technologies that are subjectively (and very rarely objectively) superior to alternatives.

At least we agree on the ignorance of managers and executives :)

It is difficult to pin down your argument, since it isn't clear if you are talking in anecdotes about specific instances of product failures or if you are describing the entire marketplace. Assuming your claim is about the latter, you are missing the context of the general trends: yes, most of the "new crop of tools" that come out every few years fail. However that is in line with most new products -- over 90% of new software products that are released every year fail, so it shouldn't be surprising that tool products fail at a similar rate.

However, at what point are you throwing baby out with bathwater? Just because most of the workflow products are crap, doesn't mean there aren't a few innovative ones that truly improve productivity and deserve to be used.

Finally, you are confusing programming and writing workflows or designing business processes. Very much like BNF grammars are an effective way of describing parsers, flowcharts (or workflows) are an effective way of describing invariant, sequential operations. Neither are an effective general purpose programming language.


At least we agree on the ignorance of managers and executives :)

Heh.

programmers who prey on the ignorance of managers and executives to convince them in uselessness of productivity enhancing technologies so that the programmers can enjoy building their own productivity enhancing technologies that are subjectively (and very rarely objectively) superior to alternatives

I'm not sure I agree with that. It's true that programmers often want to build something instead of buy off-the-shelf solutions. But in my observation, they're right as often as wrong. Then again, it's true many programmers prefer their own intellectual gratification above all else.

You're quite right that I haven't surveyed all recent workflow systems and my generalization shouldn't be applied to all of them. I'm talking about a pattern I've observed and am highly skeptical of.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: