Fog Creek Software
Discussion Board




Softare and Object Oriented Design

Curious, as I am growing, learning more, working more, I have found that I can't do anything without going through some kind of formal design process, creating a set of UML documents or models or whatever, even for small projects.

And a couple of years I would have never been excited to design anything, model anything, document, or test anything.

So my question, we know designing and going through a formal sofware design process is important, but what are your experiences with working with those who don't think it is important, or do you in fact spend a lot of time designing, or are you the 'screw it' and just code type?

I know that early versions of linux/unix, open-source software out there, UML is not first thing on the developers mind, or at least to not to my knowledge.

Berlin Brown
Thursday, June 10, 2004

*Corrected, I rush too damn much*

Curious, as I am growing, learning more, working more, I have found that I can't do anything without going through some kind of formal design process, creating a set of UML documents or models or whatever, even for small projects.

And a couple of years *ago* I would have never been excited to design anything, model anything, document, or test anything. *I would have considered that boring grunt work*

So my question, we know designing and going through a formal sofware design process is important, but what are your experiences with working with those who don't think it is important, or do you in fact spend a lot of time designing, or are you the 'screw it' and just code type?

I know that early versions of linux/unix, open-source software out there, UML is not first *the* thing on the developers mind, or at least *clipped-to* not to my knowledge.

Berlin Brown
Thursday, June 10, 2004

UML is not *the* first *redacted the* thing :)

Well, for one thing, UML is severely deficient in several key areas (search these forums for UML). However, I do agree that some form of formal specifications should be done before every non-trivial project.

The people here, though, tend to view everything as ‘trivial’ and so no specs ever get written for new functionality etc. and we just end up with a huge mass of code with no specs (many small spec-less changes add up).

I’ve been fighting my own small war by simply spec-ing most everything I write – be they bug fixes or new features or new programs (see closing para below). When people come and ask me about it I can point them at my specs and eventually they might think of doing it themselves. Hasn’t worked yet, though. :(

Also, I have found it beneficial to, in my ‘spare’ time, do a sort of “Extreme Programming” style approach to older non-speced programs/features/etc.. I go in and write a spec skeleton, or flesh out procedures, etc. That way instead of X specs we have X specs + various spec skeletons.  Provided the spec skeletons are not misleading or incorrect this is, in my opinion, a GoodThing(TM).

Captain McFly
Thursday, June 10, 2004

...and *that's* why software should be well designed and thoroughly tested before being deployed.  Despite your best efforts to patch, the original version will always exist loose in the wild somewhere.

anon
Thursday, June 10, 2004

As time has progressed I've found that I tend to find the design portion more interesting.  I used to love code, now I much more enjoy diagramming out what's in the system, what each piece is going to do, how they work together to solve the problem, etc.

Then, once I've done that, writing the code seems somewhat dull by comparison.  I mean, I already know I can do it, I figured out how.  I'm sure there'll be a wrinkle in the implementation, but that's a minor problem compared with just figuring out how the thing hangs together in the first place.

Not to say that code is boring, I still enjoy it.  I've just found that the puzzles in design seem to be more interesting versions of the puzzles I used to enjoy figuring out in code.

Chris Kessel
Thursday, June 10, 2004

I have learned that illustrating systems, classes & DB tables really helps he to understand concepts a lot better.

I regularly create pictures for hardware architecture. schemas, object models (class diagrams) & even web page maps to see exactly who posts where and when.

In my experience I have noticed that developers who do not do this tend to forget exactly how a system is acrchitected and never really get the whole picture.

I am really looking forward to adding this to my box 'o .net tools:

Visual Studio 2005 Class Designer
http://www.msdn.microsoft.com/vbasic/rss.xml

Gen'xer
Thursday, June 10, 2004

Ditto what Chris said.

I also find that, without a design up-front, there's no design document. Then other programmers come and say "I don't understand how this works". With design up-front, another artefact (the design document) is created.

Design up-front also means that other programmers can help to review (perfect) the design before time is spent in implementing it; and, other programmers can help with the implementation.

Christopher Wells
Thursday, June 10, 2004

I have learned from experience that writing down requirements and designing specifications previous to coding improves the quality of coding and helps maintenance. But, when it’s only about changing a few lines here and there… I feel like it doesn’t worth it…. However I force myself do update the design…

I really find interesting the design process, of course I also like coding, but for me, that is only one of the stages of software development… in fact I enjoy all the development process. 

On the desing stage, you have the requirements fresh in your mind and while you are transforming them into a model you start to visualise your final product…

isn’t it exciting?  It’s like planning your holidays!!!

Cecilia Loureiro
Thursday, June 10, 2004

Sorry about that bad link to the MSDN RSS feed - I encountered a weird clip board bug with Opera 7.5

Here is the link I meant to post:

http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/clssdsgnr.asp

Gen'xer
Thursday, June 10, 2004

Even more important than planning the design of the software is determining the needs and goals of the software. Many projects have spent considerable design time building a beautiful architecture when the actual customer need wasn't fully understood. Much laughter ensues when the entire project is gutted.

In any case, design work is some of the most rewarding work, both from a personal satisfaction and career advancement perspective. Draw a couple of boxes connected with lines conforming to the rote n-tier methodology, draw some dashed lines with a caption of "XML" or "EDI" between disparate processes, and you've created yourself a system and can claim all of the glory if it succeeds, but can painlessly distance yourself if it fails. Win win win!

Dennis Forbes
Thursday, June 10, 2004

The .NET comments-in-source-code-become-XML-documentation feature works well for documenting the contents of each class: but not for documenting the interaction between classes and between assemblies.

I'm using Word (structured text) to define/design the interaction between classes and between assemblies.

Christopher Wells
Thursday, June 10, 2004

I find the amount of ceremony, the weight in terms of documentation, formal steps, review, and so on, should match the projects criticality and size. Nothing more efficient in killing a small exploratory project than demanding a maximal RUP approach. OTOH I would be hesitant of going for a 1.000 manyear Life critical project using a minimal artifiact Agile method.

Just me (Sir to you)
Thursday, June 10, 2004

I suggest taking a look at Alistair Cockburn's Crystal Methodologies work, especially as described in his book Agile Software Development.  He describes a mechanism for choosing a process with a good balance between "agile" and "heavy".

Should be working
Thursday, June 10, 2004

Diagrams are nice and all, but in the places I've been, they haven't been updated with the code.

An out-dated diagram is almost worse than none at all, in my book.

Edward
Thursday, June 10, 2004

And software without good documentation (usually including diagrams) is almost worthless.

If you can see the goals of the project, even if it is not implemented that way today, everyone can keep it in mind when making any change (e.g. patches).

The code path may widen like a delta, but at least it is all going the same direction.

Richard C Haven
Thursday, June 10, 2004

I feel like 25-33% of my time is spent designing a system, including DB Schema and system interaction.  After that, writing the back and middle tiers is easy -- maybe 15-27% there.  But then 40-60% is spent on designing the UI and glueing it to the data tier.

Does that seem disproportionate to anyone else?

Joe
Thursday, June 10, 2004


in projects i found myself doing a prototype along side with OOP design to know how good or bad it is. to check the designs  strength and weakness.  especially when designing error (abnormal paths).

incidentally, when the boss disagrees with OOP design  opting instead for, what seems to be a practical, but cowboy approach.  i do it anyway because i know it will become apparent which is better.

max
Thursday, June 10, 2004

In 6 years of web development, I've never had a project specced by any formal system.  I've worked on dozens and dozens of existng websites (all db, most ecommerce, from US$1k to over US$300K) at 4 different companies,  none of which had any documentation other than the code. Currently I sometimes get use cases from someone who wonders if they should contain actual requirements, someone else who gives me very wordy word documents and someone else who tries to just give me al ine and a paragraph in a bug tracking system for change requests or even new albeit small apps. There is an awful lot of lip service but everyone just hopes and pushes for the developers to just get it done and they'll push back if they don't like it.  This sounds like the so-called XP practice ... just do it and do it again.  After development has begun and I've shown them what I'd call a prototype  the analysts begin to think they've designed the thing and if they don't like something it's becuase us developers have done it wrong.  When they start to say that things don't work right or are broken, I just ask "show me where it says what it's supposed to do and I'll apologize for saying it was ready for testing" ... and of course they just kind of look blankly and ask me when I can change it.

I've worked on and written ALL sorts of code. After 6 years I've grown very fond of the OO paradigm and strive to create all my apps as such and to refactor others when I can.  I do cron jobs using OO.

The best I've heard so far is to try and determine that part of an application which will change and write your code to accomdate that.  I've been reading the pattern books (fowler, gof, et. al.) ... and actually applying this to actual work.  I never liked the get/set stuff and I'm leaning towards objects in terms of responsiblities from a new book I'm reading "Design Patterns Explained".

A lot of stuff I've grown to appreciate in code is what I read in McConnell years ago.

oooono
Friday, June 11, 2004

> An out-dated diagram is almost worse than none at all,
> in my book.

Yes and no. Yes, if it's being given to you as the real up-to-date diagram. No, if it's somewhere in archives, and can give you clearer idea of choices that went into the product as it is now; a kind of a project-related FAQ -- Why was X designed to be like Y and not like Z? -- well, Z has these pros and cons, and Y has these, and blablabla. Actually, such a FAQ could be a nice addition to every project documentation.

GG
Friday, June 11, 2004

*  Recent Topics

*  Fog Creek Home