Slashdot Mirror
The Economist Tackles Complexity in IT
yfnET writes "In recent weeks, The Economist has run a number of articles addressing the ever-increasing complexity of software systems. The magazine, with typical Economist wisdom, casts an eye towards past human endeavors for lessons on how today's IT industry can succeed in dealing with complexity. As part of last month's extensive survey of information technology (see Related Items sidebar), the magazine offers insight on the limits of real-world metaphors, the perils of managing a rat's nest of obsolescent systems, and the need for 'disappearing' technology. And hitting newsstands just today is an overview of development models for increasingly large and unwieldy software projects. Among other things, this article compares the open source model to Microsoft's efforts using a quasi-open license. It also describes the 'agile' programming movement and its potential to keep even the most gigantic of projects under control."
Powerful Languages Like Smalltalk, and Lisp help one handle complexity.
There's a serious problem with agile methodology and outsourcing (I didn't see any articles on Economist.com related to outsourcing, but may have missed it as I gave it only a cursory look).
Large and unwieldy projects benefiting from agile methodologies? Yeah... when you have easy communication between the "customers" (business partners) and your IT staff.
How does that happen when your developers are thousands of miles away, in a different timezone, with a totally different culture, and don't speak your native language?
Diplomacy is the art of saying, "Nice doggie!" until you can find a rock.
People tend to make things over complex if you let them. Bosses want that technology they read about in whatever PHB read these days. Such and such wants some TLA to do some other TLA.
I know it's hard but you have to tell them that these things don't add any value in and of themselves. You want the simplest possible system that will solve the problem at hand. Really, nothing more, don't implement something because you may want/need it tomorrow 'cos when tommorrow comes it won't be right (and if it is, hey, you can implement it then).
----
This push to make [for the user] simple what is after all increasingly complex, can only hide, not eliminate the role of the nerd class, a role the article disparages because nerds are presumed, as the inventors, to have foisted off complexity on the unwitting public. Was it Heinlein who said that "any sufficiently advanced [or was his word complex] technology is indistinguishable from magic"? The wish, on the part of typical users and marketers, that all the wonders of our age and those ages coming next should all just work like magic will in fact only ADD the complexity of UI technologies that are good at hiding the guts of the systems we depend upon. The the engineers and technicians will be as needed as ever and get even less sympathy from a public that never sees directly what it is that the "nerds" are doing for them.
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
Sure, information technology is becoming ever increasingly complex; but it is also a great opportunity for companies that have the management able to deal with that complexity to excel and outperform their competition.
Drill baby drill - on Mars
Engineers love to break things into smaller parts, each part serving one and only one function, like pulleys, shafts, rotors, etc.
For really effective design each part has to serve multiple functions, like evolution is able to do: The human mouth can be used to eat, breathe, talk, etc etc.
That's why a robot can't compete with an animal- In a robot each part usually severs only one function, making the machine inefficient as a whole.
This problem is just magnified in computer software and will only get worse unless engineers start changing their tune. I think the worst offender of this philosophy is object oriented programming: It's the ultimate embodyment of this philosophy- Most big object-oriented software have only about 2-3% of code that performs any real work, with the rest only is window dressing to fulfill the engineer's urge to "modularize".
The best software I see seems to be written either in more pragmatic procedural styles, or uses better mathematical underpinnings for its structure, like you'll find in functional programming languages (Haskell, Lisp, etc.)
My apologies for living up to my user name!
Conrad Barski
The problem with trying to compare the software industry to other endeavors of human experience is that in the realm of the computer/electronics industry that most software developers are dealing with, you are near the pinacle of dealing with abstraction of complex systems. While there may be other very complex systems that on a large scale can compare to some computer networks or CPU designs, computer science is the practice of dealing with abstractions on many levels, sometimes simultaneously.
Indeed, electronic state machine digitial computing devices (also called computers) have proven so successful, with the software abstraction dealing with the various levels of abstraction, that they are used in the controlling of other complex systems, from air traffic management, urban water system management, freeway traffic monitoring, and law enforcement dispatching. You've seen them, and they are out there.
Some very talented engineers have done a surprisingly good job of simplifying the tasks and reducing the abstractions to the point that all you need to do for the most part is plug it in and watch the gizmo do its thing. What this article in the Economist seems to be doing is complaining that the job isn't finished, and that complexities in setting up a computer system for some project is more difficult than it should be. That is primarily due to the fact that the author is using products that don't comply with standards (a real problem if standards don't exist yet for a certain concept or technology) or they are using the wrong tool for the job, like using a hammer to put in a few screws. Sure, it will work, but it is aggrivating and sometimes takes quite a bit longer to get the job done, and can damage things around it as a side effect. How many software/electronic gizmos out there do you know get used like that?
While I'm willing to acknowledge that I don't know everything there is to know about the management and organization of complex systems, I would be more inclined to get the opinion on such a subject from a computer programmer than from a plumber.
Can you imagine someone telling Adobe to reduce their Photoshop interface down to one or two buttons? It would make no sense simply because editing a digital image is far more complex a process than 'search the web for these terms' to a user (though both may have similarly huge code bases behind them).
You hit the nail on the head. Software is complex when used to solve complex problems and easier for simple tasks.
A simple accounting package such as QuickBooks can seem tough to use for a user who doesn't have a basic understanding of bookkeeping. OTOH some software is so easy to use that people take it for granted. My girlfriend needed an office suite on her computer so I installed OpenOffice. Because one word processor is very much like every other wordprocessor she started using OpenOffice right away and had no problems even though the only other word processor she used is WordPerfect.
To paraphrase oo doesn't make messy code, messy people who mis-use oo make messy code.
I think the main problem with what, aparently all of us, have seen with oo code, is the universities. The coding style that is taught in universities makes for really ugly, unmaintainable code.
If you cram 100 abstractions and modularization into a project in university, you get an A and every one says how clever you are to have used all of these features in your project. Do the same in the real world and you are left with unmaintainable blech.
People have to learn that the various oo features are there to help them simplify their code, not to make it more complex. If using a particular modularization technique, say an interface, doesn't remove complexity then don't add it.
Another really bad thing that people do is add code for some unspecified future purpose. Maybe they are creating a class that does some math, they need an add method and a subtract method, so they think, what the hell, I'll add a multiply and divide too. Why? All this does is make the code less readable. Never implement anything that you don't need right now.
I hear this every damn day. 'We need to make it simple', 'It is a simple service' or 'It is a low option service'. This may work fine for the sales and marketing drones that make their commission off selling unnecessary services to uninformed customers, but as long as there is _choice_ out there, the backend is going to be complicated, and somebody, somewhere is going to have to known how all of it (or at least a major part of it) works.
Try all you want, but unless the entire IT industry decides to switch to one massive global device that we all plug _directly_ into, you can't make video conferencing/VOIP/disaster recovery/etc through 2 LANS, 3 Service Providers and 10 different security layers a 'green/red' push button operation.
I've gotta go get drunk now....
-- I care not for your foolish signatures.
Code for rm could be implemented in C with handfull of lines. Todays alternatives take thousands of lines of code, but to an end user the second alternative is simple. User doesn't have to know what the commands are, just toss the file away, as you would with solid objects.
So there we have it, simple problem becomes complex from implementation point of view. I once had a customer who joked when I delivered them a new system that calculated the price and basic layout of the systems they were manufacturing, that inspite the fact that now it took less than tenth of the time to do the calculations, that we could still improve it so it would do the calculations when he pressed a button while thinking of something else.
It should also be noted that what was impossible few years ago is now possible, because of improvement to hardware. This adds to the layers of complexity, because implementers can actually use modular approach instead of optimizing at lowest possible level.
Aren't these the same people who tried to tell us that "comparative advantage" meant we should give up our manufacturing and all get degrees in high tech?
Many manufacturing jobs are cheaper overseas. Your point being? (ie: economist's point of view)
If you got your degree in `high tech' because of what you heard an economist say... well, you deserve what you get then.
If you're trully interested in computers and their capabilities (ie: a `computer scientist'), then your job cannot be outsourced.
The coding jobs will go away---but that doesn't mean there aren't plenty of non-coding things to do (like design, research, etc., until we have computers walking and talking around the world there are still plenty of opportunities it IT---most of which pay off big time no matter where you do them).
It's about time people with computer science degrees realized that they weren't training to become a code monkey.
"If anything can go wrong, it will." - Murphy
I must have read Groucho as opposed to the real thing: Marx's theory of value is if anything, too moral. Marx criticizes 1800's religion because it told people that suffering on this earth would be repaid 10 times over in heaven. When you consider the society that Marx saw, England during the industrial revolution, it's really hard not to consider that kind of religious thought evil and manipulative.
Marx saw, just like we can see in today's US in a smaller scale, how religious beliefs can be twisted to make people act in a way that goes against their, and most people's, best interest. Marx belived that morality and religion are not synonymous. In many cases, religious beliefs can be completely immoral. Thus, he favored a society where morality was rational, as opposed of just be dictated by a book.
If you don't belive that morality can exist without religion, you should get out of the house more.
I think the problem is usually implicit type conversions rather than operator overloading. In particular, allowing almost-random conversions between a concrete type such as a number and a string form is just asking for trouble: it's great for quick 'n' dirty scripts, but a child's toy in a grown-up world for serious projects.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.