Team Leader Hates Design Patterns, Engineering!

The team received the following link in an email from our team leader along with an enthusiastic endorsement of the article's central tenets:
http://www.joelonsoftware.com/items/2009/09/23.html

The article, entitled `The Duct Tape Programmer` basically promotes an idea which is summed-up briefly by the following quote:
`` When you are done, you might have a messy go-cart, but it’ll sure as hell fly.``

For go-cart, read `Application`. The author argues that `Design Patterns` is a dirty phrase; that multi-threading is dangerous, and that multiple inheritance sucks.

Here's another quote from the article: [Quote]
Here’s what Zawinski says about Netscape: “It was decisions like not using C++ and not using threads that made us ship the product on time.”
Peter asked Zawinski, “Overengineering seems to be a pet peeve of yours.”

“Yeah,” he says, “At the end of the day, ship the fvcking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

My hero. [End Quote]

The author (and his hero) also dislike unit testing (?!) The motivation for this approach, as the article says, is that sometimes you need to go from zero to shipping in 6 weeks. Then you don't have time for pretty code.

Of course, I agree. If something needs to be done urgently, then urgently is how it should be written; but I'd sure as hell hate to have to come back to maintain that hastily-written cr@p in a few months (which is almost guaranteed to happen) because it'll be spaghetti code. I mean let's face it - where's Netscape now???

At any rate, my response to the team leader was that tools are just that, and nothing else. Overengineering an application is bad. That's because it's overengineered! Over-anything is bad, that's what it means in the English language: overeating, overdrinking, overexercising... but no one, surely, is arguing against eating, drinking or exercising???

Long-time members will probably remember my rant in this very same forum when I had just resigned from a horrible job with an 90+ project solution driven almost entirely by abstract classes, interfaces and delegates - empty implementations galore! It was a freakin' nightmare, and my gut-instinct was that the project had gotten away from even its own designer. This is a shining example of overengineering. On the other hand, to go for a blanket ban against unit testing, multi-threading, design patterns and other detailed (but not necessarily complex) engineering tools, this seems akin to robust and obdurate ignoramusness (to coin a phrase).

I am especially disagreeable with the team leader's stance, especially in light of the fact that his T-SQL code is littered with magic numbers - Select blah From BlahTable Where blahColumn In(232, 433, 33, 22, 55, 553) - what the fcuk those numbers are meant to be is anybody's guess, but it's alright because the app has to go out in 6 weeks. Need something more in the app? No need to revisit/rethink the design - just stick a new column into a table. So okay, we've got dozens of columns in hundreds of tables in dozens and dozens of severs (here's yet another email from the Head of Development asking if anybody knows what YadaYada table in BlahBlah server is doing!)
but at least the app is going out in six weeks (and coming back in seven).

So, ladies and gentlemen, your comments please?

I dont know what to say really... being against multiple-inheritance is one thing (one stupid thing) but being against multi-threading and unit testing as well?? what the hell.

Have you actually said to him - "dont you realise that by coding things badly now, we are going to cause ourselves more work in the future and make it harder to maintain?" and if so, what is his answer?

Don't mistake engineering for overengineering, but I can only agree that the cult of process is strangling essential progress today.

And while multithreading can be useful we're seeing a lot of non-essential gratuitous multithreading these days that can be avoided by proper use of asynchronous processing and events.

asynchronous methods and events use multi-threading though...

From the sounds of it that team leader is ready for retirement.

Tis a sad thing to realize there are others out there with that same point of view too....

Zawinski is correct and your team leader is right to endorse the article.

The point is that certain people enjoy process to the point where they are more interested in the process than the results. Once they reach this point they hamper business because they are more interested in carping on about design patterns than actually writing useful (if messy) code.

People like this tend to end up in politics.

I have worked with a team of people (Java programmers) on a product which our company was intending to ship as a combined solution. It seemed to me every design pattern that could possibly have been applied had been incorporated somehow. Every buzzword was there: servlets, XML, XSLT, AJAX, and so on. After several all-day meetings with the team I was still unable to comprehend the architecture of the product.

Ultimately, they were not able to make it work, we could not ship, and no business was done.

I do tend to agree that multiple inheritance is more dangerous than beneficial, but it really isn't an issue now that I work in VB.NET. As for design patterns, I think they are more reasonably discovered after the fact. If you have sufficient experience, your design will fall into a pattern. That doesn't mean that you have to MAKE it fit a pattern, nor does it mean that you have to know about, or even recognize the pattern to implement the code.

For example, I have always been interested in neural nets, though I have also avoided really learning much about them. Recently, after reading a couple thorough, yet accessible, discussions on implementing neural nets, I realized that I had already included them. However, a true neural net has a severe limitation (the hidden layer) that is foisted on the design because it is "the way to implement things". Not knowing about a true neural net design, I had simply avoided the limitation. In my current robot design, the neural net pattern will be there, but it will be obscured to any purist because there will be no hidden layer.

I agree with Zawinski as well. Most software is far overengineered. Yes, there should be SOME design and planning, but the fact is, in order for your business to make money and in order for you to retain your job, you need results more than pretty, mega-easy to maintain code.

By the time you implement every design pattern and finally have your codebase perfected, your codebase is totally obsolete; and needs to be scrapped and re-written from the ground up anyways. How's that for all those easy-to maintain design patterns you implemented?

Multiple inheritance I've had little use for. Multithreading though, I use often, but only in spots where I need it and typically only asynchronously, i.e. "Fire and forget" threads. Unit testing I've never done. I don't even know what it is or how to implement it. At one time I tried to read up on it and figure it out but decided it was far more effort than it was worth; and our software was already running vastly more bug-free than our competitors and even some major commercial packages out there so it was a moot point.

There's always time to iron out the architecture of your codebase in future revisions. Typically, every new version we make a feature-list for, I try to slip in the time for one or two internal revisions. Am I going to move all my database code into some totally separate tiered data layer? No, but I can go through and make sure I'm implementing Parameterized SQL in all my code which was something I learned after the codebase was established and maybe implement update and delete methods into my data classes rather than handling them in the form's code. It's not a complete rewrite but it is an incremental step in the right direction. Enough steps, and not only does your codebase become that nice, easily-maintained machine, but with 8 revisions behind you instead of 1, the company is happy and making the money it needs as well.

While software can easily be overengineered it can be even more easily underengineered. This usually reveals itself as heavy reinvention of almost every wheel out there.

You'll see lots of this in threads in these forums. Everything from hand-coded sorts instead of using sorts already available in Windows to "suck in the whole text file and do Split() after Split() on it" to process CSV input instead of using support already part of VB and Windows to large blobs of convoluted API calls instead of using a standard component.

Sometimes this is necessary in order to meet special requirements but it shouldn't be the default option as it seems to be so often here.

How far you should engineer is entirely dependent on the nature of the project. If I'm bunging out an internal app involving 3 or 4 forms I'm not going to start worrying about factory patterns and multi tier architectures. To be honest I'm probably not even going to worry about the occasional bug in it (provided it's not corrupting data). On the other hand, if I'm developing (as I am at the moment) a full business system covering marketting, telesales, sales, order processing, after sales service and manufacture, all of which have to integrate fully, then you better believe I'm going to want the thing to be as well designed and robust as possible because if it isn't it'll collapse before we get through the initial implementation, let alone the subsequent enhancements.

I think in Zawinski's case he was probably right to keep the level of engineering and design low for two reasons:-
1. They were developing a browser. It serves a very isolated function and probably benefits from a simple architecture (I have absolutely no experience of writing a browser so I'm likely completely wrong about that). In that case a heavily engineered solution probably would have been overkill.
2. (and this one's more important) At the time they were developing it they were a tiny company in a straight up race to market against microsoft. The decision to get it banged out in a quick and dirty fashion wasn't to do with producing the best possible system in the first pass, it was to do with getting out there and grabbing the market share. Failure to do that would have meant that the subsequent maintainability of the product wouldn't have been relevent because they'd have been stone dead before it ever mattered.


edit> By the way, multiple inheritance rules!! We've used it heavily in the current project and I really haven't regretted that decision. Mind you, we used it in the framework that we subsequently develop from so the part of the system we use it in is quite isolated and it was developed and locked down (sort of, we still make the occasional change) right up front. That's probably helped keep things organised. In our ongoing develop we generally inherit from a single class (usually a form or user control) in the framework, we certainly never inherit from more than one and I think, if we were, that might lead to some confusing code. Like anything else it's a tool. Used apropriately it's great for banging in nails. Used for the hell of it and you get unattractive dents in your wood. (My word but that was a rubbish analogy)

I think that Joel is heavily influenced by his business perspective, hence some of his conclusions. That is not a bad thing initself, I will certainly agree that having a great, extensible and cleverly written application that hasn't been sold is worth exacty $0$ for a company.

Perhaps Joel was purposefully exaggerating in order to drive his point home. Marketing and sales are what drive the vast majority of companies and as much as it pains technical guys to admit it, technology comes a distant second. Obviously there are exceptions, but in a commercial environment an application that is perfectly architected but several months behind schedule cannot make up for cashflow problems.

Here is how I have loosely translated that article, and I think that FunkyDexter also makes the same point: When coding, know how much is enough. Design patterns, threading and unit tests are simply amongst the tools of the trade and I need to be knowledgeable enough to know which ones to use, when, how and to what extend.

If I'm asked to write some code that only inserts the current time in an MS SQL database table and I turn out a complete data access layer that can be used with MS SQL, Oracle and MySQL then I've wasted a lot of time simply because I didn't pay attention to the requirements. Likewise, if I need to implement a heavy-duty fax server I'd be ignorant if I don't use threading and careless if I don't create the appropriate unit tests.

Quote:

---

Originally Posted by FunkyDexter

1. They were developing a browser. It serves a very isolated function and probably benefits from a simple architecture (I have absolutely no experience of writing a browser so I'm likely completely wrong about that).

---

You are.

Quote:

---

You are.

---

:lol: Yeah, I had a feeling I might be. They look pretty simple when viewed from the outside but I guess that belies underlying complexity. Reason 2 was the important one, though.

As a genuine question and at the risk of derailing the thread a bit: really how much complexity was there in browsers back in the netscape days? It was before the days of dynamic content and all the bells and whistles that need supporting today. Wasn't it basically just a case parsing HTML, interpretting that into a page and rendering that page to the screen? Obviously not or the early browser battles wouldn't have been a big deal but I'm genuinely curious as to what other stuff was going on under the lid.

Back in the Netscape days? About the same level of compexity as they do now...

A browser handles protocols (which means reading and implementing lots of tersely-written RFCs), document and style formats (HTML, CSS...), JavaScript (and VBScript in IE's case)... At a high level, this doesn't sound like much work, but each of those components is complex in itself.

The "bells and whistles" are all mainly evolutionary. Browsers haven't changed much. Firefox is today's Netscape. You can even still see all the "NS" references in its code.

The early browser wars were important because they defined the web as a platform for content delivery. Each side tried to do the same things, but better than the other. One consequence of that is no two browser engines quite support the same things, but without the wars I think the web would look quite different today.

People like ExitReality get press coverage for trying to turn the web into a 3D environment, but I bet you'd all forgotten that there were people doing the same thing back in 1998.

I agree on the complexity of what must have been subprojects in Netscape. You have to implement things like SSL, CSS as best as you can and try to avoid an incorrect interpretation of the specification.

Still, Netscape would benefit more from regular releases. I'm sure that their decision to scrap their code base and start over fresh was based purely on arguments made by software architects and purists. IE 6, which was a good release, made them irrelevant and their product was never used by large number of users.

I can't really say that the decision to re-engineer was bad in itself, but it ignored the reality that such a radical move takes a lot of time and resources to implement. The browser was still evolving relatively fast and Microsoft had resources to throw at their browser, hence the result. I think that Firefox is on a much better trail of regular releases that incorporate bug fixes and incremental changes.