Slashdot Mirror

No. The problem is that, with time, the company has built a large, unmaintenable ball of hair.

It's called Big Ball of Mud actually. How Big Ball of Mud emerges as an anti-pattern is that most people are unqualified to architect software systems even ones who claim to be architects. When management doesn't have people qualified to build a system but the system must be built anyway, you get... Big Ball of Mud. If the same re-write Big Ball of Mud, you keep getting the same thing over and over again. Very few people can avoid the anti-pattern without very careful thought.

.
And then there is always this old chestnut... The Big Ball of Mud.

yup, evolution implements the big ball of mud architectural pattern. http://www.laputan.org/mud/mud...

... is to be an employee with a single-digit employee number in a start-up company. Beyond that, you will have to deal with the Big Ball of Mud. Deal with it.

That's very theoretical. I've never seen any piece of software that ticks all of those boxes. Or a few of them, for that matter.

Non-trivial software tends to quickly turn into a big ball of mud. Because it works.

.
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.

Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?

We present the following seven patterns:.....

Then you must be happy to hear that the Gang of Four were convicted in the Show Trial Against the Gang of Four for Crimes Against Computer Science, which was held in the OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference in 1999. Unfortunately their disciples were not subjected to the same harsh punishments and their heresy continues to spread.

This reminds me of the BIG BALL OF MUD theory by Brian Foote and Joseph Yoder at the Department of Computer Science, University of Illinois at Urbana-Champaign.

Shantytowns are squalid, sprawling slums. Everyone seems to agree they are a bad idea, but forces conspire to promote their emergence anyway. What is it that they are doing right?

Shantytowns are usually built from common, inexpensive materials and simple tools. Shantytowns can be built using relatively unskilled labor. Even though the labor force is "unskilled" in the customary sense, the construction and maintenance of this sort of housing can be quite labor intensive. There is little specialization. Each housing unit is constructed and maintained primarily by its inhabitants, and each inhabitant must be a jack of all the necessary trades. There is little concern for infrastructure, since infrastructure requires coordination and capital, and specialized resources, equipment, and skills. There is little overall planning or regulation of growth. Shantytowns emerge where there is a need for housing, a surplus of unskilled labor, and a dearth of capital investment. Shantytowns fulfill an immediate, local need for housing by bringing available resources to bear on the problem. Loftier architectural goals are a luxury that has to wait.

All too many of our software systems are, architecturally, little more than shantytowns. Investment in tools and infrastructure is too often inadequate. Tools are usually primitive, and infrastructure such as libraries and frameworks, is under-capitalized. Individual portions of the system grow unchecked, and the lack of infrastructure and architecture allows problems in one part of the system to erode and pollute adjacent portions. Deadlines loom like monsoons, and architectural elegance seems unattainable.

Clicky the linky above to read the whole paper. It is full of useful insights for many disciplines besides computer science.

Visual Basic

I think I see your problem here...

One, the complexities of a GUI makes codes many times more intricate [...]

Here's the rest of your problem. A GUI must never bump into a difficult or mission-critical algorithm. That's supposed to be its own library, which is accessed by the GUI through a clean and solid software interface. This is a major architectural fault: a Big Ball of Mud, and some languages encourage that more than others.

My suggestion would be: get a language with a lower density of script kiddies, sufficiently popular and object-oriented (Python, C++, Java, ...), get some good programmers with proven track record, and rewrite the client. Specify that you want all functions and variables documented, and test suites; if they say "that will cost you more", show them the door. If they say "we do it anyway", that's a good sign.

My opinion has nothing to do with Joel's. Good to hear that he agrees with me though, I think he should credit me though as I thought it up first :)

My opinion is down to experience, even the sprawling codebase that no-one understands can be understood and refactored to something manageable, it may not be nice but its certainly possible, it just takes a little dedication on the part of a senior developer. Bear in mind that every project I've ever worked on, when I first approach it, is from the perspective of not knowing anything about how it works, you see why I think this.

I prefer the Big Ball of Mud link though, it shows how these projects arise and some of the patterns you can use to recover from them. Total destruction of the old and rebuild is left until the very end of the pattern.

Besides I think I said "nearly always the wrong approach". Rewrite is too often considered to be the only option when all this is needed is some professionalism, not a hacker's approach to being too lazy to try to understand the code, or a junior's desire to try the latest coolest technology. I say this because all too often the rewrite ends up as a sprawling ball of mud itself.

I stopped writing the stuff years ago because I realised that I was only making things worse. Perl encourages big ball of mud development. It's specifically designed as a "glue" language which lets you stick things together, in fact it's a sticking plaster language which allows you to paper over cracks which would be far better filled in another way.

Just another comment from a fellow old-head... I've come around to the same perspective. I've spent a good chunk of my career writing Perl, as a sysadmin (primarily), web monkey, and other stuff.

These days, I still use Perl, but in a very limited capacity. It's useful as a better awk/sed (when I need both sets of functionality and want to shorten a pipeline). It's sometimes useful for quicky hacks that are too complicated for shell (although this is rare). I've used it as a stand-in for netcat on remote systems that don't have nc.

For writing most tools, I use bash. In the end, I've found that it's faster, more maintainable, and more reliable to tie together well-written chunks of code (GNU userspace), than to try and do it all myself or use CPAN. For doing anything web-related, I use Rails. For stuff that's not a good fit for shell scripts, I use Ruby or Python.

Perl is like a really great swiss army knife, particularly when it comes to dealing with text. Like any swiss army knife, it's great in a pinch, but doesn't really hold up to serious use compared to tools that were designed for specific tasks.

Particularly perl, even with coding standards, reasonable indentation, comments etc.

I stopped writing the stuff years ago because I realised that I was only making things worse. Perl encourages big ball of mud development. It's specifically designed as a "glue" language which lets you stick things together, in fact it's a sticking plaster language which allows you to paper over cracks which would be far better filled in another way.

Now if I see myself or others considering Perl to accomplish something, I'm pretty sure there's a problem with the entire approach.

Or because it uses the highly popular "Big Ball of Mud" software architecture so prevalent among Windows developers.
 

Or he's done his bachelor's degree in Sociology and is now trying to apply it to people who do real work :-)

If he was a really good software engineer, he'd be doing that for a salary already, not hiding in academia thinking up ideas for his research project.

I've worked with PhD programmers in the past, its never a pretty sight. They say things like "but that's not the way that should be done", and the reply is always "welcome to the real world". Perhaps he should write a research paper on why projects end up in a non-perfect design or implementation instead, a "learn from your mistakes" paper to encourage better practises (eg formalise the Big Ball of Mud pattern)

Anyone who says PHP can't be used for functional programming is just not creative enough.

Yeah, another poster mentioned create_function. They also mentioned that it leaks memory.\

Sorry, I may not have expressed my opinion strongly enough with the tone of my voice. Functional programming in PHP sucks. create_function sucks. The only saving grace for "decorate-sort-undecorate" in PHP is that it's significantly faster than the version with custom comparisons... because function calls are sooo slowwww in PHP.

I actually do have a beef with this. I find PHP's method of output more natural than something like a C or C++ program where you have to explicitly manage I/O.

And if all it did was IO, that would be fine.

I'm not sure I get you. What does ?> ...stuff... <?php do besides I/O?

Do you cleanly separate your logic from your presentation, so your designers can tweak the template -- or swap it wholesale, or make your app skinnable -- without you having to lift a finger on the real code? ...If you answered "no", you're probably one of the people abusing it.

Due to the nature of the projects where I use PHP, I am both the developer and the designer. So no, I don't use a separate "templating language", because I am comfortable using PHP for both "templates" and "programs". Yes, I do separate "skins" into separate PHP scripts, which are then include()ed with a distinct set of parameters. It's up to my own discipline to make sure that the "business logic" goes in the scripts, and the "display logic" goes into the templates. If you think it's abuse, you are misunderstanding what I am doing.

...that is why it has been criticized -- if you go from static pages to PHP, there's a chance your PHP scripts are horribly designed.

That statement is meaningless, because there's always a chance your script/program is horribly designed. I'm guessing you meant to say that a bad design is more likely via an evolutionary process like static HTML -> PHP. In that matter, the nature of PHP is both a strength and a weakness—People who suck at programming would be equally bad using a more complex framework. Your tool can't make people stop sucking, because you have to be smart enough to use it right. PHP does hit a power ceiling faster (it takes more effort and discipline to keep a large PHP project clean than a large Django/RoR/Java Servlet project), but that by itself doesn't deserve criticism. See Worse is Better for a better description of why the low power level provided by PHP is not a failure.

I'd also argue that even systems like CGI or mod_perl are about as easy, for the few places I need something dynamic. When it's just a template system, I'll use something like a Perl script and static files.

CGI and mod_perl fit on the same level as PHP, in my book. Choose whatever you're comfortable with; no one else cares, as long as you don't expose it in your URLs. I'll keep on using PHP, because I know how to write secure code with PHP, and I don't care to spend the time learning the equivalent in Perl (but maybe C++, now that you mention it).

Our testicles, for example, hang from our undersides dangerously exposed, just because some protein denatures at core body temperatures. Apparently something needs to be redesigned that can't be made to work better with slow incremental improvements. Evolution's fix: make them hurt like hell when struck so you learn not to mess with them. A Microsoft-style hack. If we threw a bunch of supercomputers at the problem we might come up with a completely different protein design that would allow reproduction with undescended testicles.

Which explains the survivability of so much hackish, clumsy, but real-working software. See, software, or life organisms persist to the degree that they solve real-world problems. How "elegant" the solution is is rather secondary. Often, real-world problems are ugly, pseudo-random nasty problems that don't have a clear, simple, ivory tower style solution. I maintain a large, complex, beautiful software codebase that has the ugliest, most horrible hack of a pile of regex and scripting as its very center. The nasty hacks have been amazingly stable for years now, and work well, even if they are a serious pain to edit during the (very rare) need to edit.

It's carefully sandboxed - the ugly part sits in a single file that is itself wrapped inside a handler function, so the "pretty" part of the codebase is *never* contaminated by the ugly, "written in a day or two" hack that got the whole shebang started.

Sometimes, no matter how much you kick and scream, you have several screens of ugly case statements littered with random function calls, and you end up with a great big ball of mud.

Guess what!?!?! Look in the mirror - YOU ARE A GREAT BIG BALL OF MUD. Your body is a complex set of unclear, un-abstracted dependencies without clear boundaries. For example, we've long thought of the pancreas as a key component of blood sugar control. But recent research shows that the bones (yes, bones!) of the body also contribute to positive blood-sugar control. As a borderline type-II diabetic, I pay attention to things like this...

Millions of years of evolution (or a few years of hard work by a half-drunk God) have resulted in your body, which is a festering pile of weird dependencies. For example, if you don't get exposed to enough dirt as a baby, you end up with asthma.

If Microsoft's software is truly evolutionary in nature, that would explain its dominance in today's marketplace - it's well adapted to survive in the software environment we've seen so far, and like the dinosaurs, it will only be beaten back when the basic environment changes. (which it is)

Get used to the world of "dirty" evolutionary solutions - it's the basic building block of life itself!

If they can't tell the difference, why should they approve the team spending twice as long on the cleanup as on the prototype?

They should approve it after you explain that when they want new features or a bug fixed, it will be faster to add with fewer problems. You explain that if all projects were left in prototype stage as soon as something was working, eventually you'll end up with a big ball of mud.

Most Microsoft software sucks. I don't know where they went wrong, but some time between "Olympic Decathlon" and Microsoft Windows v1, they got on the wrong track and never found it again.

The problem is that little to no thought gets put into architecture or the long-term consequences of making a particular design decision. The result is public catch-phrases like "Microsoft LookOut" and "Internet Exploder", and of course the untold millions of man-hours lost due to systems being Pwnz0red. I believe this is a result of creating a horrifically complex big ball of mud and then treating the UI as a sort of afterthought, a glossy sheen. The resulting product looks nice from a distance but in fact is is just a dorodango - a highly polished ball of mud.

The problem with that architecture model is that nothing is ever stable. There's too much complexity to test properly, so only the most common pathways are tested and/or optimized -- but anything out of the ordinary is extremely difficult to do.

Why is it that Microsoft Windows has so many "assistants" and "helpers" and "wizards" -- active agents to guide you through basic tasks? They are a symptom that the UI is deeply flawed. There are effectively no wizards in MacOS X or in Ubuntu -- the UI is designed well enough not to need them.

Some units within Microsoft seem to do well. The Word group used to turn out first rate stuff, and the group editing tools in 21st century versions of Word are very good. But that is an exception -- most of the stuff just sucks.

Indeed, this is why software is prone to the phenomenon known as The Big Ball of Mud. A possibly well-designed original program gets encumbered with feature requests over its lifetime until it devolves into a piece of software that is unrelated to its original intentions and is unmaintainable by the developers that have worked on it.

In such cases, many times the best thing to do is examine what the overall purposes of the software is supposed to be and start over from scratch, but engineer the new solution, rather than cobble it together.

As a programmer, I currently can't even handle HTML generators, and prefer to code (most of) my web pages by hand.
I wonder what becomes of Big Ball of Mud spaghetti code when translated into XML. How much worse can it become?

Another key issue may remain efficiency: compile and link times have remained issues for large projects, as program complexity keeps up with performance increases.

I'd bet on pure text source code for serious programming in the next 10+ years. Which doesn't mean that the Visual Basics and Mathematicas of tomorrow won't choose and XML-based storage format.

Provided that you're working with a damn good architecture and not mud - http://www.laputan.org/mud/mud.html. Working that long tends to affect your thinking, and chances are that you'll try to only get it *working*, instead of trying to design it *nicely*. Bad design is the first step to buggy code.

...a big ball of mud. The thing that you really don't want to throw out and redo from scratch is the documentation that ought to accompany a project - if the behaviour of the code is fully documented, then a you can decide what if any functionality you throw away when rewriting the code.

I believe that this is a result of design. If you have a well designed system, then a vulnerability is probably a result of a simple programming flaw. Fixing such problems is usually just a matter of changing a few lines of code, or at most perhaps adding a layer of error checking.

If you have a system designed like a Big Ball of Mud, then a vulnerability is likely to be the result of unanticipated interactions between different modules. When you try to fix that, then you are just changing to a different set of unanticipated interactions. Fixing such systems often involves making sweeping changes across all of the modules that you can think of that interact with the problem module.

It's not surprising that "fixing" something in such a system breaks other things. All you can hope for is that you break less than you fix, and the breaks won't be discovered for a while.

These are in order of priority...

1) Make it work. It's very important to have something to show/sell!

2) Make it work well. Once you have something to show, it's important that it generally behave as expected

3) Make it work right. Finally, once you have something working and doing what's expected, it's important that sound design and engineering principles are used, particularly in maintenance to ensure continued ability to meet the needs as they evolve.

This is where I'm more and more becoming an advocate of Extreme Programming. Primarily the concept of code evolution - that you quickly evolve the code to fit the needs as they evolve.

My most common evolutionary path is to start with a hack, and make it clearly known that it's Q&D, and then when needs overwhelm it, we consider it a "proof of concept" and rebuild/rewrite as needed.

Typically, when the Q&D solution isn't enough, the resources exist to pay for the "right" solution.

Another great reference work is the Big Ball of Mud, covering the various reasons why software develops the way it does, and highlights the various forces at work.

Your requirements will not change drastically

You are wrong with this assumption. Refactoring (like other XP practices) are for software whose requirements changes constanly.

Your code will be needed for a long time

You don't need the code for a long time because if you never refactor your design (not only your code), the system, with a lot of patches, becomes a Big Ball Of Mud, and then you need to throw away your code.

The point isn't only about "Refactoring", is about the evolutionary code (refactoring is only a small technique for to allow future evolution in parts of the code, cleaning the code to allow more drastic design changes).

The best example about software evolution is Smalltalk (note that the book "Refactoring" is based on ideas taken from Kent Beck's book "Smalltalk Best Practices Pattern").

The base code of Smalltalk comes from the 70's. And the recent version of comercial Smalltalks (with support for all the buzz tech like XML, WebServices..) still uses a lot of objects who evolve from the original implementation.

(offtopic - Talking about Smalltalk, I don't know why any company doesn't made an object based OS, based in the concepts of Smalltalk, for example Squeak is a good example of an Smalltalk Enviroment -or Object Enviroment- that can be used as a complete OS desktop).

Your requirements will not change drastically

You are wrong with this assumption. Refactoring (like other XP practices) are for software whose requirements changes constanly.

Your code will be needed for a long time

You don't need the code for a long time because if you never refactor your design (not only your code), the system, with a lot of patches, becomes a Big Ball Of Mud, and then you need to throw away your code.

The point isn't only about "Refactoring", is about the evolutionary code (refactoring is only a small technique for to allow future evolution in parts of the code, cleaning the code to allow more drastic design changes).

The best example about software evolution is Smalltalk (note that the book "Refactoring" is based on ideas taken from Kent Beck's book "Smalltalk Best Practices Pattern").

The base code of Smalltalk comes from the 70's. And the recent version of comercial Smalltalks (with support for all the buzz tech like XML, WebServices..) still uses a lot of objects who evolve from the original implementation.

(offtopic - Talking about Smalltalk, I don't know why any company doesn't made an object based OS, based in the concepts of Smalltalk, for example Squeak is a good example of an Smalltalk Enviroment -or Object Enviroment- that can be used as a complete OS desktop).

On the plus side, the fusebox framework brings some organization to what would otherwise be a collection of interconnected pages of script. Fusebox is fairly straightforward and a developer can use it with a single day of instruction, so it can be a very useful application development tool.

OTOH the resulting application is usually a single large executable which handles all functions (and pages). This is not in itself a bad thing, but appears to be precariously close to the Big Ball of Mud methodology of software development, although it really isn't.

Until something better comes along for scripting languages complex applications can be organized using fusebox. And at that time it shouldn't be difficult to refactor an application from the fusebox framework to another, better methodology.

The REST methodology approaches applications development from another perspective and is grounded in the structure of the WWW: it may be the next place to look for organizing WWW applications development.

Whether or not it's approved by management, reworking code to make it cleaner is the only way to keep the program from turning into a Big Ball of Mud.

One of us is seriously wrong about GoF patterns, since IMHO, hardly any of them are better handled with databases. Representing a resource as a single, constructed-when-needed object (Singleton)? Distributing functionality by method rather than subclass (Visitor)? Having a collection of objects expose the same interface as any one of those objects(Composite)? None of these seem to involve databases. Most of the examples in the GoF book are of GUI systems and text editors, and these don't imply databases.

Why is the Linux kernel such a mess, crick here.

And the kernel is still a rancid ball of mud.

Read this and tell me that the Linux kernal isn't a rancid ball of mud.

First, read this essay: The Big Ball of Mud. It is an interesting look at why, when we all know that spaghetti, gnarly, twisted code is bad, that it happens anyway (hint: it may mirror your understanding of the problem).

Ignore the "don't touch it" naysayers. Even before it's done, it'll be much nicer code to deal with. You can make decisions with less nagging doubts. You'll code onward with gusto. You'll be able to accurately predict the names of methods without looking them up.

Test the current state of things at all points through the process. I'm hoping that you have lots of automated tests you can run everytime code is checked in; if not, make them FIRST, before the overhaul. You are majorly diverting the intent of the code at hundreds of points; you can run astray in so many places that the above naysayers would be correct. Constantly assure yourseleves that the code is working. Go out of your way to ensure that the code is buildable and runnable, even to the point of writing scaffolding you know will be soon thrown away.

Burning a little incense every day in obesience to the Gods can't hurt, and will make the room smell nice.

mahlen

Shantytowns are usually built from common, inexpensive materials and simple tools. Shantytowns can be built using relatively unskilled labor. Even though the labor force is "unskilled" in the customary sense, the construction and maintenance of this sort of housing can be quite labor intensive. There is little specialization. Each housing unit is constructed and maintained primarily by its inhabitants, and each inhabitant must be a jack of all the necessary trades. There is little concern for infrastructure, since infrastructure requires coordination and capital, and specialized resources, equipment, and skills. There is little overall planning or regulation of growth. Shantytowns emerge where there is a need for housing, a surplus of unskilled labor, and a dearth of capital investment. Shantytowns fulfill an immediate, local need for housing by bringing available resources to bear on the problem. Loftier architectural goals are a luxury that has to wait. -- from "The Big Ball of Mud"

First, a little background info about me. When I first got into touch with *nix systems I started to use vim. I was amazed by its richness of features. (I liked those infamous keystrokes too.) Later a friend of mine introduced GNU/Emacs and tried to convince me of its superiority. It was a hard task. I was used to my way of writing vim macros for everything and jumping around the screen/file with only a handful of keystrokes. He finally succeeded. Some of the features that seduced me:

• integration (ftp, file manager, news browser, cvs client, ...)
• support for various languages and file formats (Java, Lisp, Python, ...)
• everything-a-function which results in easy extension of the functionality
• lot of support packages pre-installed or downloadable

The problems started to show up when I wanted to implement more serious functionality.

Failure 1 - better forward-statement in Java
I was thinking of some new motion commands in Java/JDE mode like forward-statement, mark-statement, finish-statement. Yes, I know there are commands whose name implies this functionality. Unfortunately in reality they are almost useless because their interpretation of 'statement' is not what one would expect after reading the grammar of the Java language. In short I wanted functions that know more about the content of the file. It turned out soon that implementing these functions may well include parsing the file and that would imply serious programming in Lisp (or interfacing an external parser). I spent some time trying but gave up later.

Failure 2 - mix iswitchb and imenu
Ok then. I am not prepared for writing serious extensions for Emacs yet. But how about a smaller one? I like the iswitchb package very much. (For those who do not know it: it eases the pain of using C-x b or switch-to-buffer by adding incremental search and history to the selection of buffers, much like the functionality used in the location part of IE and other browsers.) My idea was to mix iswitchb and imenu (which gives you the ability to jump to semantic elements in a java file like methods, inner classes and so on.) I thought that using the selection method of iswitchb added to imenu would greatly improve my editing of Java files. I tried very hard and got quite far away but then I had to give up. It proved not to be easy to extract the selection functionality from iswitchb and insert it into imenu. In its final state my code worked but it was full of bugs.

(There were several other little features that I could implement, but more advanced functions needed a lot of work to implement.)

These failed attempts forced me to stop for a while and think about the possible causes. My first thought was that maybe it is me who is not skilled enough for the task. Then I tried to analyze the problems I faced during coding. I found that it was scarcely ever the case that I could not design a solution for the problem at hand. The problems came when I tried to implement and insert it into Emacs's envirnment.

Emacs badly needs a mature OO language Emacs based on Lisp. Lisp is a functional language. Emacs badly needs object-orientation even at the cost of abandoning Lisp. Emacs has a lot of data structures with functions to modify them. Buffers, frames, windows, points, marks, faces and so on. But the functions are separate entities from their intimate data. Everything is a list and you got a myriad of functions to manipulate those lists. You have a buffer? You get buffer-name, get-buffer, rename-buffer, buffer-file-name, and so on. I thing in OO this kind of function naming is called 'data-envy'. All these functions should belong to the buffer object and not to the global namespace.

Language features instead of conventions in packages
Two words: global namespace. Lack of a nice naming and packaging system become more and more iritating as you want to do serious programming. Besides Emacs should be separated into a couple of modules with well-defined interfaces. Nowadays function-variables play the role of interfaces. Unfortunately this method is not well-suited for defining complex abstractions.

Lisp is used in a procedural way, anyway
While browsing the sources of several packages I had to realize that Lisp was not being used as a functional language. It seems that most of us is locked into procedural thinking and Lisp only changes the syntax not the logic. The majority of functions in the majority of packages could be translated into C/Java without seriously changing the general outline. (I did some programming in ML and I know how different a functional program can (and should) be.) Lisp became a burden which cannot be dropped because of historical and emotional reasons.

Weak coupling should be enforced by the language not by conventions
Packages get into intimate relations with each other's hook functions, global variables and inner workings. Let's take an example. Suppose you have a strange obsession and want to fork a new Emacs strain which gets rid of the evil transient-mark mode. What percentage of the code base will be affected? Do you have any clues to identify those parts? (Maybe grep, but I would not bet on it.) I had to sourly learn that this functionality and references to it are scattered all over the place. I often felt that I was working on a Big Ball of Mud.

Mud results in low-quality packages
The base packages are fine. But if you look at other packages which claim to have complex and advanced functionality you find sloppy software. And this is due to the strong coupling of code and unclear interfaces in Emacs. I think that most authors simply cannot cope with it after a certain point. Most of them have a great idea at the beginning then they implement some nice 'one-liners' to get a feel of it then they get stuck when the real work begins. That is why there are so many half-finished, low-quality packages. I think that with the current code base the price of developing a sophisticated package is daunting.

Escape while you can
Emacs is bogged by its heritage of supporting a wide range of terminals and systems while being unable to develop further because of the aforementioned reasons. The only conceivable remedy would be a total reconstruction preserving the basic ideas and design. Unfortunately this is very unlikely.

Richard Gabriel gave this speech at theOOPSLA 2000 Conference (Object Oriented Progamming, Systems, Languages & Applications). There are some other interesting keynote presentations there including a piece on Adaptive Software Engineering (PDF Alert!!).

You can download a .pdf of the essay, or if you can't view pdf's, check out the cover.

Richard Gabriel gave this speech at theOOPSLA 2000 Conference (Object Oriented Progamming, Systems, Languages & Applications). There are some other interesting keynote presentations there including a piece on Adaptive Software Engineering (PDF Alert!!).

You can download a .pdf of the essay, or if you can't view pdf's, check out the cover.

The article said of the approximately 200 days a worker spends at work, 47 days are spent developing new code and the other 150 are spent fixing bugs and doing testing. This gets back to the statistics about how few lines per code a person generates a year.

What would be more interesting to learn is how many those other 150 days are broken down into design, testing, and bug fixing. Working on a large project myself I would certainly agree that not enough testing is done and the brightest aren't always the same set of people doing the design.

I'm not sure if, however, all the labor shortage could be avoided by designing things in the first place. I believe the Mythical Man Month postulates that as software projects and their teams grow in size, their complexity grows disproportionately faster. Sure it is easier to design something that is small that work just as you intended. Try throwing 40 people together each doing that with a mediocre architect and I'll tell you the results aren't pretty. Even worse are the people usually put on maintenance.

Everyone should go read the Big Ball of Mud. Really. Everyone that has ever worked on a big project will be able to relate to its contents.

I refuse to follow ads that simply say "Click Here!" My time is worth more than that.

"Click Here" really is bad form. A link is supposed to describe where it goes to. You should be able to rip out all of the links on your web page and list them, with the linked text, and have a handy list of links - just like Slashdot does. It only takes a few seconds worth of creativity to come up with a meaningful link.

Also, "click here" assumes that you're using a mouse. That may be true now, but it shouldn't have to be so. How do you suppose a voice interface to the web will work? Most likely, if you want to "click" on a link, you will say the underlined phrase. For example, when viewing this post with a voice-capable browser you should be able to simply say "Google" or "Crypto-Gram" or "Big Ball of Mud" and be taken to the appropriate place. It's better than having to say "'click here' number 8... no, the one in the seventh paragraph... not that one, go left, up, up, click!"

Really - the people who created hypertext actually did think of this stuff. HTML was supposed to be device-independant, not "optimized for a box on a desk running browser-of-the-week with an 800x600 screen on a 15" monitor and a default font size of 'tiny'".

</RANT>

Well, basically, Tampa (or at least our office) is in a timewarp, I've heard my new boss refer to Linux as "underground crap" and "freeware," as well as a constant din of saying "Linux sucks" anytime any problem arises. (The application we were left with was a Big Ball of Mud, but this has nothing to do with Linux. The new guy finds it convenient for pushing his agenda, though, to blame every single problem on Linux and say, "If this were NT, we'd be done already.")

Well, that being said, every Linux box we've gotten here in the Tampa office he wants to "blast" (his term for re-format) and make into an NT/2000/Tinkertoy-whatever box. Even if they have valuable information on them that will be lost... and I haven't been able to effectively defend Linux against this onslaught. I mean, how can I when the guy has no problem lying if it will prevent him from having to learn something non-Windows? It's his word against mine, and he can find FUD to back up his side to counter any pro-Linux research I might do. (He's more experienced than I am, and even though I've been at the company longer he's considered senior.)

So, people shouldn't think that Linux is winning the war of the office. Maybe in CA it is, but here in the stix, Bill Gates' tinkertoy-set still reigns supreme.

Any tips on how to fix this situation would be greatly appreciated... though I realize I'll probably get a lot of Windows-head who seem to frequent Slashdot now telling me I should go with the flow....

Pilot Light? Check!

One thing that gets me about the OSS community is the over-reliance on C.

Petrol(UK->US Translation - Gasoline)? Check!

I mean look at Gnome and GTK+, it based on some ugly C struct kludge to enable pseudo-object-orientation!

Flame-throwers are go!!

And then there is KDE 2.0 based on even uglier preprocessor commands.

I mean WTF is going on. The method of production in OSS is innovative, but the resulting programs end up being MS ripoffs. We need some true innovation regarding what we develop and the tools we use to do so. Because lets face it, most app level programming would really benefit from C++, or even something like Eiffel and the concepts of design by contract. Using pre/post conditions and invariants as in B notation, one can almost guarantee the correctness of one's program. (Eiffel and B were both in part developed by Betrand Meyer, he also played a hand in Z notation).

There is also an interesting project called EDMA That is trying to create an enviroment in which objects can be inherited from after they are built, a bit like CORBA, but IMO better.

void SelfPromotion {

I am in the early stages (i.e. thinking a lot and getting myself confused) of developing a Dynamic Object Enviroment to support reflection and better models of code reuse through selective "pilfering" of code and structure from other objects (Classes don't exist, only instances, although instances may share code). No links, or anything much to speak of as yet.

}

Anyway I digress, we should start thinking about the tools we are using, and ensure that they are suited to the job. For most things, the performance benefits of C, are not really crucial WRT anything outside the Kernel.

Cheers,

faichai