Anyone who thinks Shantytown is an appropriate description for all open source software either doesn’t understand what is meant by Shantytown or hasn’t worked much with open source. That’s not to say open source is any more or less immune to the pathologies listed, but projects like the Linux kernel are not built by unskilled laborers and do not lack infrastructure, planning and regulated growth. gcc may be free (as in beer and speech) but it is by no means a “simple tool”.
I’ve worked on plenty of Shantytowns and believe me, they aren’t pretty. I wouldn’t consider myself an “architecture astronaut” (http://www.joelonsoftware.com/articles/fog0000000018.html), but software written by skilled professionals where some effort was made at long-term planning and growth management is usually far better than cobbled-together balls of mud.
Andrew: “Again, do you have any real programming experience?”
Andrew, you totally missed the point of every item mentioned in the article, and then had to resort to a personal attack? Do you have any real programming experience, or are you one of those self-taught VB users that just think they know how to code?
I’d suggest you re-read the original article, and then read some of the responses to the article (except yours), and then try again.
Clay: “That’s not Fulton County Stadium.”
So what? Does it matter? It’s a picture of a stadium being taken down.
Why do people feel the need to nitpick minor details? Is it that you can’t grasp the big picture being presented, and instead have to find a minor issue to quibble about?
So, has anyone worked on a project that was planned (or refactored) so well that maintenance is a joy (relatively speaking), new features can be added logically without screwing up the main plan, etc?
Just finished doing some maintenance to a project at work that I was not involved in with the writing. It was extremely well put together. It didn’t take me long at all to figure out what my coworkers had done before. Several times, I was able to use methods that had already been generalized. Other times, I found code that was identical to what I needed to make embedded in another procedure. Refactor method, pull it out, pass some parameters, test the calls from both places, tweak, and check it in.
And yes, this was maintenance on a 1.0.
Another project I’m working on is a version 7 but a reconstruction of a piecemeal growth app. A lot of thought went into the rewrite also.
Now architects draw up these beautiful works of art. Everything is perfect on paper. But don’t go looking behind the dry wall at most these places. Yea, the major structural parts are sometimes ok, but there is a lot of duct tape a bailing wire in there also.
Maybe in the multi-million dollar projects you have good design and good construction, but there is also tons of read tape and regulation.
Or maybe some small handcrafted projects where the designer/constructor is paid very well and has almost unlimited time you get a result to show off to the world.
The fact of the matter is our world works pretty darn good even with all the less than perfect engineering. In fact I don’t know if our world would be possible if perfection and beautiful code was what we all strive for. Between the Sears Tower and a handcrafted china cabinet for the wifes special day there is much work to be done and it doesn’t all have to be magnificent, just adequate.
I saw Brian Foote give this talk at the most recent OOPSLA in Montreal. It always surprises me how you can find metaphors for Software Engineering in disciplines that seem like they couldn’t be further from it – and the metaphors are usually pretty deep!
I’m bitter, angry and I hate you all. Isn’t that proof that I’ve worked in the software development industry for a long time?
Probably the best comment I’ve seen, by someone I totally disagree with on most of his other comments.
Software development can be incredibly frustrating if you care about the software. Most of the industry is in the “big ball of mud” stage of development and seems inextricably mired in their ignorance and short-term outlook. It’s another aspect of the whole 80/20 thing Jeff posted about recently. (Except I still think we’re lucky if it’s 90/10).
On the other hand, sometimes I get to work on a ball of mud and clean it up a little, usually when no one’s looking. Better to light a candle…
A lot of the antipatterns described in Jeff’s post tie into something I call the Just Barely Good Enough syndrome. I work for a small software company (5 developers), and there’s always way more to do than we have time for. As long as something is just barely good enough to get the job done, even though it may be hard to use, frustrating, or downright painful, improving it usually loses out to features required by new clients or other business realities. Unfortunately, this applies to pieces of the shipped product as well as internal tools!
I’m not saying I have a good answer for this, because if we don’t please our clients we don’t keep the lights on. Maybe the one thing I’ve taken from this is to try to take the time (if possible) to implement something a bit better than Just Barely Good Enough, because I’m probably going to have to live with the results for a long time without an opportunity to improve it later.
Some of the bridges designed for The Rocket are still in use by todays high speed 125mph trains…
Modern Engineering practices say they got it wrong, “over engineered”… The joke is the people saying this are not building anything that will still be standing in a 100 years time
I’d really like to thank Frank and Matt Morris for responding to my question about if there are any well architected products out there. I know it might be stupid, but it really gave me some hope.
You 2 have me so jazzed right now that I’m going to start to abstract out a bunch of stuff that was haphazardly added to some of our smaller projects and get them together…then I’ll move onto the big one.
So, Frank and Matt Morris, you may not know it, but you really have made a difference to me today.
“People often talk about bad development like it’s some kind of law of gravity or natural decay. But that’s rubbish. Most developers ending up with a bad system have created a noose for their own necks. They want to appear helpful and to appease management. So they accumulate technical debt, and a few years later end up in a state of technology bankruptcy. To avoid this you need to grow a spine, get good at negotiating, and learn how to state the case for good development in business terms.”
Mr. Ginger has it bang on. Bad software is not inevitable. Bad software is a by-product of developers lacking the spine to stand up to management, of management not understanding technical debt and its consequences, of laziness for the up front work (i.e.: lack of design) and, in general, bad software practices like “go to your cube and write code”, no or superfluous code reviews, no or superfluous design reviews, etc.
My primary weaknesses as a developer turn out to be that I loathe working on big balls of mud and I can’t work well on a team with developers I do not respect. These are the roots of the problem but what actually drove me out of the software industry and likely will stand in the way of me ever returning is that I could not work on a team with developers who were content to work on the balls of mud or who believed there was no way to avoid them. I could not respect those developers and would come into conflict with them as they either worked against efforts to improve the mess or implicitly encouraged management to ignore technical debt by accepting every stupid requirement and request with nary a complaint.
I’m not saying my position is correct - I could be the problem child here for all I know. However, I hope my point of view may give those who feel the ball of mud is inevitable or those who whine about balls of mud but don’t proactively fight against them to pause for thought and consider that maybe, just maybe, they are the problem child.
“I’d seriously like to find out from other software developers if anyone has been involved in a project that you were very proud of the code.”
Yep
I’ve kicked off the development of replacement subsystems a few times now. You get decent config, testing etc in from the beginning. Make sure the conditions are in place to be able to refactor and release over the longer term. Don’t cave in to expedient fixes. You can keep going for years with no problem. It’s possible to salvage stuff that’s veered off course too, though that can be harder.
People often talk about bad development like it’s some kind of law of gravity or natural decay. But that’s rubbish. Most developers ending up with a bad system have created a noose for their own necks. They want to appear helpful and to appease management. So they accumulate technical debt, and a few years later end up in a state of technology bankruptcy. To avoid this you need to grow a spine, get good at negotiating, and learn how to state the case for good development in business terms.
Of course this is not particularly easy, which is why so much software is in a terrible state…
KenW: "So what? Does it matter? It’s a picture of a stadium being taken down.
Why do people feel the need to nitpick minor details?"
I’m not defending the prior nitpicker, but a key detail which was ommitted from the analysis of the short life of Fulton Stadium was the fact that the 1996 Atlanta Olympics had already constructed its replacement. It cost Ted Turner a lot less to retrofit the Olympic Stadium into a baseball park (he actually demolished 1/3rd of it, it was too many seats to fill) than to build a new one from the ground up.
So part of that example should have been “if you have a huge external source of capital, that always helps”.
How do you not know you are creating spaghetti code? I mean, if you are not already just an all-around bad programmer, in which case you probably are not reading any of these books or blogs anyway.
I mean, if you are not already just an all-around bad programmer, in which case you probably are not reading any of these books or blogs anyway
This was exactly my point on the “Two Types of Programmers” post. We have to reach out to these folks to bring them into the fold, because they’re the majority.
