"3. You probably don't want to be writing your own framework anyway (or even seeking out a third-party one, for that matter)"

Matt,

There is no Better or Bigger, More Inclusive and Ubiquitous framework than the Internet upon which to hang Tempting Fruit/Novel Applications.

And XXXXStream Care and Conscientious Attention to Detail will allow Stealthy Coding which Run with Privileges to be Deployed by Proxy.

Indeed, it is explained for the Microsoft environment here .... http://www2.sys-con.com/webinararchive.cfm?pid=wc_soa7_d2_s4_t1_greschler&registered=on

"3. You probably don't want to be writing your own framework anyway (or even seeking out a third-party one, for that matter)"

...from the co-author of...

"Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to drive functional tests and unit tests from use cases, using the <b>Spring Framework<b/>, JUnit and Enterprise Architect."

Nobody else see the irony here? :-)

...and I can't help we're falling into the "extreme programming"-type nonsense of pointing out the bleedin' obvious and selling it as revolutionary thought.

Sorry Matt - nothing personal.

"...and I can't help we're falling into the "extreme programming"-type nonsense of pointing out the bleedin' obvious and selling it as revolutionary thought."

Sssssshhhh, for chrissake don't tell anyone. Damned fine money to be made.

"You probably don't want to be writing your own framework anyway (or even seeking out a third-party one, for that matter)"

Did I read that correctly? Dont write your own framework and don't use someone elses? So.... no frameworks ever?

Sure you don't want to make something excessive, but at the same if you make it too stupid then in some ways you will become like your code.

I believe in simple elegant code. Looking at KISS (keep it simple stupid) refers to the developer regarding the stupid part.

Probably the most important part of development is requirements gathering, the rest can be done by a monkey that follows orders. Slick designs are a luxury afforded to those who have to look towards the future.

This is just another reworking of the "second system syndrome" that goes back *at least* as far as Brooks' "Mythical Man Month"

"You probably don't want to be writing your own framework anyway "

That's a great big stinking "probably", and requires an "unless" clause of almost infinite length, but which could probably be summed up as "unless you are working on a project that neatly lends itself to, or requires, this kind of approach".

I've one application under development that would be pretty useless without such an approach (a cryptanalysis tool which requires the ability to have further analysis functionality modules added by the user as they become aware of different techniques and approaches) and previously coded one which actively required a plug-in framework (Linux based custom PalmOS interface for multiple custom application conduits).

Or what about an experimental video processing application, which requires the ability to add various custom filters and processing steps in an arbitrary (and mutable) order along the path from I to O, the nature of most of which are unknown at the time of coding (hence the 'experimental' nature) ? That just screams out for a framework approach, and indeed for a pluggable architecture.

Perhaps if all you do is tedious corporate data slinging and MIS reports, you may wish to shy away from the "framework" approach, but adopting it in even measure at the correct parts of your system can still have benefits (e.g. pushing MIS report design and customisation back to your users, where it belongs)

"(or even seeking out a third-party one, for that matter)"

Sure, sod things like QT, .NET, WPF, J2EE, Spring, all the PHP and Python based frameworks, Rails, and all the rest of them, just write all your own code to do everything from the ground up, that's a far more useful way to spend your time and money, and besides, reinventing the wheel is great fun.

Hell, why not just code everything in assembly!

@Rich

"...and I can't help we're falling into the "extreme programming"-type nonsense of pointing out the bleedin' obvious."

Or more accurately, "what was bleedin' obvious for the narrow range of projects that the author has worked on, once it has passed through their methodology zealot filters ".

I hate to keep posting the same response to the Agile/Xtreme crowd, but in programming, one size most definitely does _not_ fit all, and I'm tired of being told that it does.

Rich - nothing revolutionary about this, as the article states this is a "growing pain" that we all tend to go through - obviously the earlier in your career the better.

On frameworks, the key is in this part of the article immediately following your quote: "But sometimes, you do want code to be re-usable because you can see exactly where it'll be re-used. ..."

(In other words, use a framework if you must - think Occam's Razor).

Ivor - If there's damn fine money to be made, I must be missing a trick somewhere (I'm just in this gig for the groupies anyway ;)

Anyone looking to The Reg for serious development insight probably isn't too advanced for refreshers like Don't Overbuild.

But really the point here is watching out for devs creating Valhalla rather than coding to requirements. The author could have been explicit that he was sketching out one boundary of the developer world rather than the center, but honestly it pretty apparent that's what he was aiming at. There's clearly a time and a place for reuse, frameworks and serious architecture, but even in those cases you frequently run into places where a little more design (and design review) would have resulted in a lot more clarity and maintainability. It's not revolutionary, just common sense that isn't always that common. I guess it comes down to making sure project goals are clear from the beginning and everyone keeps in mind how much reuse is needed, how much flexibility will really ever be used and what costs to simplicity are justified. (Oh wait, that's what the article actually said.)

I know a few people who's automatic reaction to any problem is which pattern can I use to solve it...

I believe this is known as being pattern happy, this is not a good thing.

Our current so called 'architect' is like this, and to make things worse chucks the whole J2EE stack at the simplest of problems - sad thing is he doesn't even do it properly.

"Hell, why not just code everything in assembly!"

I'm with you all the way their mate. Where do I sign on?

Surely "Grand Design" does include the idea of simplicity? So the "Grand Design" which is referred to is not Grand? Well it should not be called Grand Design then!

Anyway while I can agree with the author in my experience most developers whose work I have had the "pleasure" to see are definitively not the audience for this article. The reason being that they certainly are not "ambitious" enough to do any "Design" what so ever - never mind "Grand". Even large projects I have had the unfortunate benefit of looking into had generally speaking not exactly been characterised by "design" - more like confused, panic stricken trial and error run "hacking". These "programmers" should not be surprised if their system is not exactly reliable... (never mind "secure"). Unfortunately I believe that articles such as this one might lure some of the less "ambitious" software developers to believe (wrongly) that their personal "non-Grand-Design" approach ("trial and error"?) is the best one... Never realising that they actually never learnt how to "design" a software solution with their brain engaged in the first place and so if they ever tried it - it was always flawed. So the conclusion that bad design is worse than no design might be true - but I still believe that we should aim at a slightly higher level of professional responsibility and make an effort to do "Good Design" which should include some competent reflection on the context of design and thus be real Grand Design... and thus Grand Design is not some wolly anal retentive application of techniques without competent reflection...

Usually when the author posts a comment you get an exclusive The Register icon so that we know it's really you.

Might want to look into that.

BTW thought the article was good. Frameworks are so 5 years ago anyway. ;-)

trouble is far too many long in the tooth developers need such statements and still don't get it :-(

Generalising after one case is only slightly better than generalising after no cases.

Understanding where the requirements have come from gives you a bit of insight about where they are going, with a little mild speculation. The best I've managed is to write stuff that's easy to debug and change its behaviour, and give a fair stretch past the original brief, with well known limitations.

By definition, the most generic code does absolutely nothing.

I found this article very interesting. I have worked with people who are happy to write code with no real design, and with people who go so far over the top it is quite unbelievable. I find the people who over-design are the hardest to work with since they adopt a stance similar to 'the emperor's new clothes'. That is, if you don't see why their code is far superior, then you must be a useless programmer.

For example, I used to work with a programmer who read a few articles online and then refused to ever use 'if' statements without splitting the code out into some kind of factory class. The reasoning being that if you need to branch the logic once, then you may well, in the future, need to branch it in the same place for a different reason.

Unfortuantely, articles on how to create good design are plentiful. Articles on when not to introduce yet more patterns to your code are in very short supply.

Spend 12 months working with morons who think reuse is what copy and paste was invented for and you'll be ramming Martin Fowler's back catalog down their throat before long.

Conversely - spend 12 months working with seemingly intelligent developers who can't code "Hello World" without implementing 17 of the 23 GoF patterns, and you'll find not only is the frustration of working with such people that much greater - there's nothing you can do to change them. They're right - and the more they over engineer their project, the more right they get. Furthermore, you're a hinderance to progress when you try to steer these people back onto the path of common sense.

This is a problem that is different for everyone - your own experiences (or lack of them) will drive your behavior towards one end of the spectrum or the other. The skill is in keeping away from both.

Personally - I'd rather work with the morons... the path to common sense is easier to find from their end.

I actually agree with overall principle that over design is a bad thing.

I was genuinely asking if I had interpreted that point correctly.

"programmers must recognize that any time they're creating reusable code, they're writing a framework"

"You probably don't want to be writing your own framework anyway (or even seeking out a third-party one, for that matter)"

To my understanding, these 2 sentences combined result in the conclusion that the author is arguing: "dont use frameworks" and "don't write reusable code".

This is obviously ( hopefully? ), not what the author meant.

p.s. I can't decide who you're insulting with this sentence:

"Anyone looking to The Reg for serious development insight probably isn't too advanced for refreshers like Don't Overbuild."

It's either just me, the entire regdeveloper readership, or the regdeveloper itself. Or all of the above?

"I'm just in this gig for the groupies anyway ;)"

There's groupies?!!! Damn no-one told me.

http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12

A framework is a library and then some.

But, the problem with frameworks is they come too bloated, and if you want to add a simple feature that is not there, it becomes very hard to achieve without getting to the guts of the application (and then gutting).

If a framework is modularized and easy to alter then we don't have a framework, instead we have a python module or set of python modules :)

What I think you mean is badly designed , under designed, or over engineered.

Good design is sensitive to needs. Bad design is not. No design is pretty random. emergent design is a joke. You get my drift.....

What is often forgotten is that every programming language is, in and of itself, a generality-of-purpose abstraction layer.

If you try to make something too general-purpose, it **always** gets bloated. Sometimes it's better to write a piece of code that just does what it's supposed to do well. If you ever need to make it do something else later, then it can be modified as and when the need arises. And if you don't, then you didn't waste time the first time around.

Any good object-oriented project will contain at least a semblance of a framework... It'll offer a hierarchy of objects that perform specific types of tasks usable by other programmers.

For example, if you're building an online service, you'll probably create some kind of account object that handles everything related to a given user, right? And once you've built it, you shouldn't have to rebuild it every time you want to do something new with that data. You might create a child class that extends it a bit. But why duplicate your work over and over again? Do it once, correctly, and reuse it.

I think what the author is getting at is that people are pattern-happy these days, and new grads seem to think they've got to re-implement Struts every time they put up a web page.

I knew a guy like that. Here's a true story:

I once worked on a document tracking system. It would have used .Net, with web services on a middleware server providing database access, and most of the ASP.Net user interfaces were derived from abstract classes I built as a sort of interface prototype. Lots of functionality was built into the base classes, so all the individual UIs had to do was implement what was unique to them. It was nice and clean, and used inheritance and polymorphism to simplify the maintenance I anticipated happening in the future.

Due to some very weird and unfair bullshit going on in my office at the time, the whole project got handed off to a bunch of consultants.

The first consultant wanted to use a framework based on COM+, even though the transport mechanism he wanted to use was going to be deprecated by Microsoft. Because MY code was pure web services and ASP.Net based, he didn't know how to convert it to his framework, and told my boss that my code was good, but he didn't understand it. It would all have to be rewritten. So he took all the code that related to business processes and scrapped my UI and web services, and started rewriting.

Shortly after, another consultant defeated the first consultant in mortal combat (basically, made him look dumb in a meeting) and HE decided to do the whole thing using Struts. But he didn't want to download Struts; he wanted to write his own version ON OUR DIME. The bosses thought he was brilliant and gave him the go-ahead. I had a short and hostile argument with him in which he told me that "page controller" was no good (despite my approach being the Microsoft-standard one) and that he would use "front controller" (i.e. a Java-like approach). I told him he was an idiot; he told me I was one. He won.

He worked on it for a year and a half, and just before I left the company, he sent out an email claiming that his framework "wasn't working out" and that they were going to download some port of Struts for .Net and try to recode for that.

If I'd have been left alone, the project would have been done in two months. It ultimately took almost two years.

Maybe that's what the author was talking about?

OO is not appropriate for the vast majority of websites.

Script/includes/css are all you need, and, if sensibly written, are far easier to maintain than .net/ruby/blahblah. The latter have nearly doubled the cost of developing in my company.

The detail of websites simply evades encapsulation.

OO is for stuff the website calls, not the website itself.