<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Here's a long rant. I loved writing this. It was cathartic, and I just couldn't stop myself. I hope it doesn't annoy anyone toooo much.</div><div><br></div>I guess my own background has resulted in some antipathy to the business computing culture. Before going to law school, and then again recently, I did application development for organizations whose main line of work was not software development. I did so for perhaps twenty client organizations the petroleum industry and then later in law-related fields<div><br></div><div>There are aspects of the culture in such settings that are hard to take. For as long as I worked in that environment, the source of the nastiness was usually the central IT department, which went by various names such as "Data Processing", "Computer Department", etc. These folks had certain convictions that were, to them, beyond challenge. There was/is some validity to their view, but they took it too far. A rough catalog of a few of their notions might include:</div><div><br></div><div>(1) Existing tools (meaning s/w and h/w already available in our organization) are adequate for all computing-related purposes. Such tools should always be centralized, never distributed. Innovations make it too hard to administer our data centre.</div><div>(2) There are no hard programming problems. Everything boils down do getting requirements from users correctly.</div><div>(3) The current flavour of the month s/w development methodology will solve all your problems related to (2) above.</div><div>(4) Computer-science guys are a problem. Soon automated methods will make those geeks obsolete.</div><div><br></div><div>To blather on a bit more I'll give an example of the absurdities these views created in one project I worked on..</div><div><br></div><div>In the late 1980s I worked on an engineering problem that boiled down to (a) a gas pipeline network design problem with an interactive aspect, and (b) solving a large sparse system of nonlinear de's to test optimality of the network design.</div><div><br></div><div>The IT department had a huge IBM mainframe. They ran ADABAS and NATURAL (business, meaning commerce tools; look up Software AG in the web). They flatly refused to accept my recommendation that we use (the then emerging) graphic workstations to do the interactive network design. They insisted that we could use their dumb IBM 3270 terminals hooked up to the mainframe. (These clunkers will be as unfamiliar to younger guys as vacuum tube computers. They were about that obsolete even at the time.) They also insisted that all data modelling, storage and retrieval use inverted-list database technology (ADABAS). And not just for persistence, but for run-time modelling of what were inherently graph structures. They insisted on that <i>because db technology was what they had and understood.</i> They could not conceive of the existence of problems that "business software" could not solve.</div><div><br></div><div>The IT/Business guys also insisted that we derive solutions <i>directly</i> from the output of the mandated s/w methodology. This methodology was perhaps suitable for setting up, say, an accounting system in which the domain experts could tell developers more or less how to write the software using "business rules."</div><div><br></div><div>The problem was, the domain experts in this case were engineers <i>who did not know what the solution to the problem was</i>. They fully expected those of us on the project team to research, find, adapt or invent algorithms and techniques to solve the problem. Their expression of "business rules" was no more than a statement of hoped-for outcomes.</div><div><br></div><div>This led to a year-long series of meetings run by one senior consultant (who bought into the methodology thing) in which she repeatedly interviewed groups of engineers. She repeatedly asked them "what software do you want us to write?" (These were "JAD" or joint application development sessions according to the methodology.) The engineers would sketch out the expected <i>results,</i> but when she went back to her office she had no idea what to do next.</div><div><br></div><div>After 18 months I quit because I could not take it any longer. The project never produced a damned thing, as far as I know.</div><div><br></div><div>Here is the paradigm in that culture:</div><div><br></div><div>BUSINESS RULES ==> {a miraculous non-human-mediated transformation occurs} ==> A GREAT SYSTEM</div><div><br></div><div>Right.</div><div><br></div><div>So, I despise that culture. Now that I'm on a roll, I'll say that I hate the word "business" in a lot of ways.</div><div><br></div><div>More than anything I HATE the assumption that any and all important activities in the world are a form of "business." Government, so neo-liberals say, should be run like a business. The real world is about "business." Universities are now businesses, run by administrators who pimp their institutions out to the "business community." Children's soccer teams, amateur string orchestras, photography clubs, churches, community centres, EVERYTHING should be run "like a business."</div><div><br></div><div>Well, fuck that, I say. Down with market capitalism! Death to Microsoft! Long live the revolution! To the barricades, comrades! Aaaarrrgh....</div><div><br></div><div>Whew. Now I'll eat some junk food.</div><div><br></div><div>- Dave -</div><div><div><br></div><div><br></div><div><div><div>On 2009-11-08, at 11:56 AM, Abram Hindle wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>At least business computing is about meaning. They don't care that there<br>is a computer there, they simply want process followed and these objects<br>or symbols manipulated.<br><br>It is actually very abstract in many cases and it is often grounded in<br>being actually useful to the customer who employs it.<br><br>That said, you should stay skeptical ;)<br><br>abram<br><br>Rudolf Olah wrote:<br><blockquote type="cite">Maybe it's because I've been heavy into Dijkstra lately, but "business<br></blockquote><blockquote type="cite">computing" is fundamentally flawed and fashion-driven and really isn't<br></blockquote><blockquote type="cite">worth understanding. As Dijkstra said, businesses purposefully try to<br></blockquote><blockquote type="cite">complicate things and keep their work secret in order to profit.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If you strip away the bullshit, it's easy to understand and useful.<br></blockquote><blockquote type="cite">However, that would make it *too* easy to understand and accessible and<br></blockquote><blockquote type="cite">lots of IBM salespeople would be out of jobs! Bullshit keeps the economy<br></blockquote><blockquote type="cite">afloat I'm afraid :-P<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">You should grow a beard and turn into Dijkstra or Knuth or Stallman<br></blockquote><blockquote type="cite">instead :-D<br></blockquote><blockquote type="cite">-Rudolf<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">toronto-lisp mailing list<br></blockquote><blockquote type="cite"><a href="mailto:toronto-lisp@common-lisp.net">toronto-lisp@common-lisp.net</a><br></blockquote><blockquote type="cite"><a href="http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp">http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp</a><br></blockquote><br><br>_______________________________________________<br>toronto-lisp mailing list<br><a href="mailto:toronto-lisp@common-lisp.net">toronto-lisp@common-lisp.net</a><br>http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp<br></div></blockquote></div><br></div></div></body></html>