Slashdot Mirror
Big Ball Of Mud Development Model
Lightborn writes: "The Big Ball of Mud Development Model examines exactly why so many projects (software and otherwise) end up looking like a bowl of spaghetti. A good list of things not to do when developing a project."
I've finally adopted a very game-programmer oriented philosophy towards development. Code should be written so that it is the specification, with appropriate inline comments documenting it and really clear variable names. Programmers should be extremely vigilant, and continuously roam their own code making sure that it actually reflects the current state of assumptions about the system. Whenever a change is made to the system, anything remotely affected should be proactively rewritten to reflect the change. This is pretty much how Abrash describes himself and Carmack working on Doom and Quake, and it is really successful. You keep performance up, stay in touch with your code, and never accumulate cruft. Bugs are immediately ferreted out and the programmer must never fear diving into code to tackle a big cleanup job, and can never allow pieces of code to exist that she (or he) doesn't understand.
Of course, you need massive automated tests to make sure your rewrites don't screw anything up. Designs must be extremely abstraction oriented, with a close eye to strong interfaces and bootstrapping, otherwise you will end up with so much code that it is impossible to manage the continual cleaning. And you need really dedicated programmers.
When I look at the Doom and Quake source, and the code that my own dev. team has produced, I see that the results are worthwhile. Each routine is beautifully crafted and works flawlessly. The codebase is a fraction of the size you would expect because so much effort has been put into doing everything the right way and eliminating broken or excessive code. And no bugs...
magic
For a long time I couldn't figure out why others had such a hard time fixing bugs and changing their programs, while I could do it without any problems (no I'm not trying to be arrogant or pretentious).
Then a coworker made this remark: "Ray how can you write such well-organized code in one pass?" At first I couldn't understand what she was talking about, after all doesn't everybody constantly review their code? Doesn't everybody constantly rearrange functions and classes, rename variables, redefine protocols? Apparently not.
Correct me if I'm wrong, but it looks to me like most programmers write something once then spend the rest of the time trying to get that working. They never go back and rewrite the code, they just keep adding fixes to it. How can this ever work smoothly?
I've also seen and heard a lot about processes to make a program, or anything else, come out right the first time. I don't get that either! To me, the only objective when writing programs is to make it easy to change. Period. If it's easy change, it's easy to fix bugs, it's easy to enhance, and it's easy to rearrange and redesign with hindsight.
If you want to have a good time programming, do yourself a favour: learn the tools to make global changes to your code quickly, then spend a _lot_ of effort rearranging your code and renaming things as your program evolves.
I agree with you in part, but pigeonholing all of OO as obscurantist and overcomplicated is as erroneous as overhyping it as if it were the Second Coming. There is nothing wrong with the motivation behind OO itself; the problem lies mainly in implementation. Specifically, what we now consider to be "OO programming languages" and "OO design practices" goes far beyond the original concept of both, and much of it is indeed obscurantist nonsense, which induces a huge amount of needless overhead, both of the conceptual kind on the designer and of the practical kind on the implementer. This is especially true in the case of small to medium software projects, even more so because often designer and implementer are one and the same.
Case study 1: C++. An extensive critique of C++ as an OO language for production systems, from the point of view of an Eiffel-cheerer, can be found here; in my opinion, it suffices to say that, given its status as just one step up from a C add-on, and given that, when building on such a shoddy conceptual infrastructure as C's, it's hard to conceive how one could do any better, C++ should be considered to be outside the scope of this discussion.
Case study 2: Java. Now, Java is built from head to toe for maximum OO. This is incredibly intrusive to anyone who wants to do some real work using it, as opposed to just drawing nice schemes and writing UML models. Java is built to enforce those styles and concepts of programming which the designer felt to be correct. It's languages like this which give OO a bad name, and they should be shunned.
Case study 3: Perl. Perl was built to be a scripting language - in Osterhout's original conception, a "glue" language. Thus, practicality being the most important goal in it, it's easy to understand why Perl's OO is as it is. Specifically, it doesn't exist per se; no special syntax or semantics is enforced for OO programming, in fact all of it is built upon simpler, pre-existing constructs - specifically, taking advantage of an isomorphy between modules and classes, objects and references (via abuse of the bless() and ref() functions), methods and namespace-local subs. This makes a transition to OO practices easier as a project grows. It also allows one to implement the concept of an object as he sees fit - usually the slot approach is used, using hashrefs, but there other approaches for specialised cases - including objects as indices into class-wide property arrays, an approach described in "Advanced Programming with Perl" and which is useful for when you need many objects and creating a hash table for each would be a waste of space. The discussion of OO in Perl could be extended further, but it suffices to say that, in true Perl form, it restrains from imposing a paradigm on the programmer, trusting instead that he knows better.
Case study 4: Smalltalk. Smalltalk is widely considered to be the godfather of modern OO (yes, Modula had something called "OO" before Smalltalk, but a quick glance at both languages will make it clear right away that most of what we call OO today was fathered by Smalltalk); this, combined with the widespread availability of "OO software design tools" for the environment, could lead to some people blaming it unfairly for their current issues with the paradigm. In reality, when using Squeak, a computing environment integrated with a derivative of Smalltalk, I've found the use of OO in programming the system to be perfectly natural, in contrast to the uncomfortable feeling that you get from using, e.g., Java. Part of this comes from language design itself, which makes the concept ubiquitous in a very straightforward and graspable way, but most of it comes from the environment, which is fully built on objects. In the Morphic system, you can "see" and "touch" - inspect, manipulate, delete - all objects alike. The user- and programmer-levels are intertwined, and so instead of programs, methods are the elementary user-level executable unit; this removes one unnecessary level of encapsulation, leaving all objects free to talk to each other, without being first streamlined into the procedural mold enforced by the "program" concept. All of this, plus the elegance of the Smalltalk language, makes for a system which is very easy to program, and which leaves relatively little to be desired. Thus, I consider Squeak to be a paradigm of well-used OO.
Hell, I think I've said more than I set out to... I hope at least some of it is of any use.
To the editors: your English is as bad as your Perl. Please go back to grade school.
I'm really glad to see this. In my experience, the great flaw in the OSS model is the quality of the code. Can we be honest? The vast majority of it is complete crap, developed by amateurs with absolutely no clue how develop to professional standards.
The OSS community needs to establish some quality standards. Linux code is relatively new, but this is going to bite everyone in the butt as the code gets modified more and more, and software rot starts to rear its ugly head.
Unfortunately, the vast majority of OSS developers are not very old (less than 25), and don't have the perspective to appreciate trying to maintain 10 year old code that has been modified 20 zillion times.
Mark my words: Unless coding standards get real important soon, OSS is going to collapse under its own weight. "As long as it works" is not good enough.
--
Sometimes it's best to just let stupid people be stupid.
The vast majority *is* crap. But the stuff that is important, libc, the Linux kernel, GCC etc. isn't. If you look at Windows there is lots of third party software that is complete junk. The case is the same with Linux. But the "big stuff" is all big *because* it's good, well designed software. OpenSource can produce crap, anyone armed with a compiler (standard on most UNIX's) can produce utter junk. But will that junk be used? Will anyone even know it exists? Of course not.
Both OpenSource and Closed Source development can produce junk software. And both can produce great software.