The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Using patterns where they won't be understood

I've recently been asked to rework a helper application for managing and editing some structured data files used by the main application here. To me, it seems obvious to use a pretty much out-of-the-book MVC pattern as the application design. However, when I take into account the skillsets of the other developers that might later work on this app, I can be reasonably sure there's a high probability that the next person to maintain this app won't know what MVC is.

Now, speaking for myself, if I had met MVC before reading the book, I would have been utterly confused, and any maintenance I would have done would either have been conceptually wrong or would have broken something. So the question is, in this new app do I keep it clunky and thus more widely maintainable (but tending to become spaghetti over time), or do I do it 'properly' ?
Larry Lard Send private email
Wednesday, February 08, 2006
IMO, do it properly, but also write a technical design document that:

1) Introduces the MVC design pattern.

2) Details how you implemented the MVC design pattern.

3) Provides references to other works the reader can use to get even more information on the MVC design pattern.
Former COBOL Programmer Send private email
Wednesday, February 08, 2006
>the skillsets of the other developers

Presumably, they're going to know what MVC even IS?  I don't. 

How do you feel about big fat sections of comment lines in your code?  All for the technical design document, if that's the way your shop works and you know someone will even think to look at it in six months.  If not, comment the heck out of what you're doing and tell posterity where to start looking when they come in later.  If that's an option in this system.
Feeling stupid Send private email
Wednesday, February 08, 2006
4) Prominently reference your design document in the comment prologue of each of your files...
Former COBOL Programmer Send private email
Wednesday, February 08, 2006
> ...pretty much out-of-the-book MVC pattern
> ...if I had met MVC before reading the book

I know what MVC is, what it's supposed to do but I've never really grokked it, never seen a simple template or example and had that Aha! happen.  What book are you referring to, I'd like to read it.
Chris Nelson Send private email
Wednesday, February 08, 2006
I would just document the design in an external document or in detailed header comments for the classes and members. Really, I don't think there is a question as to whether or not you should do it - you should! Look at it this way, the other developer(s) that are later assigned to modify the code will need to understand whatever it is you decide to do. You can either make it the pile of useless crap that they are used to or you can make it a well-designed module. I vote for the well-designed module as they might pick up some tips that will lead them to write better code.
A. Nonymous
Wednesday, February 08, 2006
MVC is nothing more than INPUT => PROCESS => OUTPUT.  As such, the so called pattern has been used since the invention of pointed stick and clay tablet accounting.  Why not skip the BS and represent the pattern in its simplest form?  That way you have a chance to solve the problem.   

If all you want to do is impress the newbies, PHB's, and various IT zombies, go ahead with your original plan.  Use the BS and assure failure to solve the problem. 

Who knows?  You might get a promotion and pay increase because you proved you are no threat to your PHB.  In any event, your PHB will be greatful for the new pile of words he can use to scam his PBH.
Lionell K. Griffith Send private email
Wednesday, February 08, 2006
Thanks for your comments all, I will do some light documentation and put it in VSS with pointers to it in comments, I think.

Chris Nelson: The book is <>

Lionell K. Griffith: Yeah, and the Mona Lisa is 'nothing more than a painting'.
Larry Lard Send private email
Wednesday, February 08, 2006
the mona lisa IS nothing more than a painting. when it ceases existing, nothing will change, no lives will be affected. if it had never existed....nothing. it's humans that ascribe meaning and value to an otherwise inanimate object with no intrinsic value other than the materials it was made with.
your everyday knob
Wednesday, February 08, 2006
Does the Gang of Four give it a different name? The link above doesn't have the words "model" or "view" anywhere on the page.
Wednesday, February 08, 2006
Huh, how about that, all this time I thought it was straight from the book but it actually isn't! More on MVC at <>
Larry Lard Send private email
Wednesday, February 08, 2006
Yeah, MVC isn't from the gang of four. But it is still a well known pattern. Producing a pure MVC architecture is actually pretty hard though. Very few applications actually accomplish it. But that doens't mean that you shouldn't strive to get as close as you can.

As far as using MVC terminology, I'd say not to overdo it. It really doesn't matter to the other programmers what it is called. They will learn to program in your environment anyway. And they will be much more productive after a couple of days/weeks of learning. The long term benefits will be there regardless of what you call it.

Don't give up on a good design just because you are afraid that the other programmers won't get it at first. If they NEVER get it then it is a sign that you need to bring in some better talent. And it sure won't hurt your resume or personal knowledge to have lived through the experience of "doing it right".
Wednesday, February 08, 2006
I actually think MVC is not the best pattern to use in this case based on the description of the problem. The "view" aspect is... unnecessary; it is unlikely you'd ever need to make a desktop interface, a web interface and a cell phone interface to the same core functionality.

Furthermore, since this is a helper application that works on an arguably well defined, structured data file, abstracting out the "model" aspect is probably also overkill.

That leaves you with nothing more than a basic "open and load file", "process data", "save and close file" paradigm.

More to the point (and answering the original question), I don't think management expects the application to be so complex that you do need a formal design pattern and yes, the next person to work on the project won't expect it either.

Lionell is being sarcastic, but he has a point - it looks as impressive as hell and it will get the job done, but it introduces a lot of unnessary pain - kinda like using a Ferrari to bring home a new bedroom set.
Wednesday, February 08, 2006
When in Rome....
Wednesday, February 08, 2006
> kinda like using a Ferrari to bring home a new bedroom
> set.

It's funny you should mention it because I've actually _done_ that.  I don't recommend it, but if you can't avoid it just make sure you open the doors _before_ you tie anything to the roof - those little windows are a b*tch to get in and out of.
Ernie Send private email
Wednesday, February 08, 2006
I guess you have created a new design pattern. Let’s call it the "lowest common denominator pattern”. The idea behind this pattern is to avoid design patterns altogether because the average programmer is too stupid to know them and will probably undo all of them anyway when doing maintenance work.

Just do it the right way. Why worry about those that can’t grasp a very well known design pattern. The fact that they are uninformed should not be your problem.
Thursday, February 09, 2006
Well I find it hard to believe there are really UI programmers who havent at least heard of MVC, though grokking it is another matter.

I learnt most of my design patterns when I was a junior, doing maintenance on well written code developed by others. I did made quite a mess of some of it, but I pretty soon managed to get with the programme.

Having a fair dinkum example to work on will help them learn the patterns when they otherwise would never find to to read about it in a theory book like GoF etc...
Java GUI Programmer
Friday, February 10, 2006
"MVC is nothing more than INPUT => PROCESS => OUTPUT."

Nah, it's more than that, but it's still dead simple. You gotcha model - that's a model of yer problem, innit. And yer view - that's where you view your problem - UI stuff. Yeah, And then you got yer controller. That's ... um .... for controlling yer problem. Innit. Yeah.

That'll be 560 of yer merican dolls, please.
revert my gangerfore
Tuesday, February 14, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz