Jump to content
  • Advertisement
  • entries
    146
  • comments
    435
  • views
    198844

Design

Sign in to follow this  
Washu

244 views

Design

Here's something you should do.

Typically, when I'm going to start a project I work out a document that details the goal of the project. This gives me something to work with initially. If this project is for a client, we'll go over the document, and make changes as needed so that it will reflect what they want, initially.

After building the document I typically will build some use cases for project, based on the document. This gives me some idea as to how I want the application to behave, and how I will probably structure it as well. The other thing is that when building a use case you will typically find other optional or alternative use cases that you hadn't thought about. Note that optional != alternative. An optional use case is one which isn't required, but can be added without conflict. An alternative use case is one which when added precludes the use of another use case.

So you say to me, "But Washu, we've done all this work and still don't even have a single line of code to show for it!" This is true, but I have an idea now as to how the application should work. This is important, especially for the next stage, which would be prototyping the application.

A prototype, for me in many cases, is a throwaway prototype. Now, after the recent topic on the forums, I started looking at my older projects, and noticed that I tend to use a throwaway prototype a lot. The thing is, the prototype may have been thrown out, but artifacts developed during it's inception are not. Those artifacts typically go into a repository for reuse, either in their current form, or in a refactored form. This prototype is a good way to get client feedback, just be very sure that they understand that it's a prototype and that it has bugs, and is not representative of the final product. You must be very clear on that point, otherwise they can (and will) misinterpret your prototype.

The prototype is also useful because it will typically reveal some optional or alternative use cases that I did not think about in my initial design. You find these both through client feedback and through just the development of the prototype application.

Developing a Prototype
Gotta be careful here, you must always remember that this IS just a prototype. Spending too much time on it will mean you'll have to rush for the real thing. The goal here isn't to build a fully functional application, but to build something for the client to give you some feedback on.

First things: Use TDD. This will save you in the debugging arena. While I've seen arguments for and against TDD, I will say this: I have never been let down when using it. It has saved me from making stupid bugs, and it has saved me in finding some of the most complex and horrifying bugs you can imagine (Things like the program reporting the incorrect amount of memory usage when the day ends in a 6 and the week was odd, and yes, that was a real bug).

Secondly, build a design up front. I typically do it from a high level down, usually designing how the systems interact, then going lower from there. I, however, never drop below the component level. I have reasons for this, but I'll get to that later. Note that the design you come up with will evolve as you write the prototype, and that the components you build will end up in the repository. Those components, and even entire systems if you can, are known as artifacts. The advantage here is twofold, firstly you are getting feedback from the customer, which will help to direct the development of the final application. Secondly, you are building components that will end up being used in the final application, and if you're lucky, in other applications.

Now, I mention that the prototype shouldn't have a whole lot of time spent on it removing the bugs. That isn't to say that you shouldn't remove bugs, it's just that you shouldn't attempt to work out all of them. It should be mostly wrinkle free though, especially if you have practiced TDD and refactoring.

Anyways, that's it for now. Comments, as always, are welcome. Next time I'll focus on some issues with upfront design that you should avoid.
Sign in to follow this  


5 Comments


Recommended Comments

I hate throwing away code, which is why I restrict my prototyping to sticky-notes on the floor.

Share this comment


Link to comment
Personally, I setup a password protected wiki page on my website which I use to design systems, write down ideas, "todo" lists and bugs. It's been incredibly useful, I feel like my productivity increased several order in magnitude when I started doing that. It's basically a living design doc, and the best part is that I can read it from anywhere in the world as long as I have a net connection. It's really great.

Share this comment


Link to comment
I strictly adhere to using as many use-cases as possible.. both at home and at work. I find them amazingly useful for designing as well as implementation.

I am brushing up on my design skills of the high level picture though, I am not the greatest at 'putting it all together' yet but it's coming along.

Share this comment


Link to comment
Quote:

While I've seen arguments for and against TDD, I will say this: I have never been let down when using it.

YAR MATEY!!! I have to totally agree. There is also a very tangible value to the tests themselves, apart from the assistance they give in the development process, and that is confidence in your code. I know that, if I've written good tests (and good tests are easy once you get the hang of it), and my code passes the tests, then I've written good code. The tests are infinitely easier to read and document than the code (though code documentation should alway be a priority as well).

For me, design is always on paper, first. I like drawing boxes and squiggly lines. I don't like UML that much, mainly because I don't have a good tool to do it with (and without a good tool, it's hell on earth). To me, there is no possible way I can know at the beginning of the project how the project will be developed (which is where prototypes come in), so design is always very general, non-standard, on paper.

I'm all about prototyping. I like to have something tangible RIGHT AWAY. Not only does it make me feel good (and on a long project, managing your happiness is just as essential to success) but it also teaches me, gives me a chance to try things out. Too many times I have implemented something and later said "Oh crap, I wish I had a second chance at that, I would have done so much better."

For example, I was given a task to write a GUI module for an architectural program. The module should allow the user to draw rectangles on the screen to represent rooms in a house. It should also allow the rooms to be moved and resized. Layers of rooms make up a floor, and only the currently selected floor is editable (uneditable floors should be rendered in grey).

My initial reaction for the prototype was "let's start with mouse input, and start drawing some rectangles onDrag". I started writing huge chunks of code to manage these rectangles, lists, renderers, picking, etc. ad naseum. It was crap, crap, crap, a typical prototype.

I took a step back slept on it. In some strange stroke or genius (or maybe it was a stroke, they run in the family), I reallized that most of my functionallity was duplicated by an MDI child window. Woo! All I had to do was make a dragged rectangle define the bounds of the window and redefine how the window drew itself. A few thousand lines of code dropped down to a few hundred. The windowing manager handled everything else from there. You can move windows, you can resize them, you can pick them, you can do all kinds of stuff to them, and I didn't have to write one single bit of it.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!