Designing your software

automatica

automatica

New member
Aug 4, 2009
74
13
0
I was curious how the rest of you go about designing your software before you start coding. What level of detail do you go into as far as making DFDs, use cases, keeping up with requirements, etc?

Personally when I'm writing something moderately sized for myself I just draw up some UML class diagrams in visio and write out the features I want in an excel document.

What level of detail do the rest of you go into for your own projects vs what you may have worked on in a professional setting?
 


It's all in my head initially.

I like to find a template that fits the general look and feel (I'm talking web apps here), then I just work it out as I go. Most of the time it never ends up looking much like the template as thing are always being added and removed.

Other times I just start slapping down the HTML, it generally looks pretty ugly, but it's probably just for my use.
 
I don't put a lot of weight into planning, but avoiding feature-creep is a must, if you like finishing projects.

When I interned at msft, developers on my team had to write out the full spec of the program before we started coding it. Great practice that I still follow before starting anything.

It was the PM's job to do the UML, interface mockups, etc, and personally I usually skip these parts because even major implementation details can and do change in the normal software development lifecycle, but before the developer was ever allowed to open an IDE, he had to verbally describe every aspect of the program's expected operation and submit it to a non-geek for review.

Then, you read-only the file, commit it to source control, and never edit it until you start V2.0. When someone asks you to add a feature, you show them the document, and tell them to email it to you with the header "[WISHLIST]" and no deadline, because your requirements are already set in stone; If you're a real zealot, tell them you'll change the document, but you'd have to start your code over from scratch.

e.g. "This is a program that will take X and multiply it by ten. The user will pass in X via command line argument, and the output will be stored in out.txt. If X is not a number, nothing is returned."

When it comes ship day, it's real easy to look at this document and say, "does my code do precisely this?" If you're working for a team, this kind of accountability is priceless. If you're working for yourself, any sort of accountability is nice.
 
I can't agree more with uplinked. Having worked multiple software engineering jobs, the most important part of starting work on any software is setting project requirements and specifications.

Since my work mainly consisted of consulting with researchers to provide additional requested features to our projects, I came to realize very early on in my software engineering experience that the process of defining a set of specifications and communicating it effectively is what gets the project going.
 
First, I work out the idea in my head. Then I usually do an outline of all the pages -> menus -> options. Then I do an iterative series of rough sketches to block out the pages (ie, where to put the logo, menu, features, etc, but NOT thinking about graphics or colors yet.) Then I develop it. Once the features are all there and working I start prettying it up.

I used to just start right into coding, but I always get hung up on the design aspect and don't flesh out all of the features when I do that. I have to work to restrain myself from fiddling with the graphics and design until the features are developed. I'll burn tons of hours on Photoshop before I even know what the pages are going to look like if I'm not careful.
 
I do the same thing.. I'm weak with design so I can end up wasting a ton of time on it. What I have been doing is making a function called template and putting the html template with in. In the template I enter some easily replaceable strings like **TITLE**, **METADESC**, **METAKW**, **SIDEBAR**, **BODY**, etc. Those are all passed in an array and then the function does str_replace a few times and outputs to screen. This is the first thing that I do, so after this step no more f'in with the design.
Being self taught I tend to shy away the planning stages. I write out a general description of what I want to do, make a list of functions and start coding.
 
I know there are tools for mocking up websites, but I just work better with pencil and paper. I'm more creative that way, and I can go through iterations faster on paper.

I use cheap steno pads (I'm a lefty, so the top-binding is great.) I have a ton of them lying around the house, with a post-it sticking out the side that indicates what project/theme that pad is for.

steno-pad.jpg
 
If its something im serious about I will get the roll of paper out, bluetack it to the wall and brain storm. I use to do this in mindjet but for some reason the paper and wall method seems to work better for me.

I then group them by functionality and pretty much have high level requirements.

Ill go back to the computer and then write what each part has to achieve and go from there.

At this point i can gauge the size of the beast, if i need to hire some labour to help I will take the time to write a requirements doc.
 
All I ever did was just use a pencil & paper. This was always easy enough for me, no need for anything more complicated. But then again I'm not building some OS either, just usually some automation software.
 
You must log in or register to reply here.
Top Bottom