Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For the independent developers, or the weeknight/weekend developers, when you are about to begin a large/enterprise project, what are you first steps to take when hashing out the pre-coding details and designs?

What are the tools you use? Do you find it easiest to keep with the traditional mechanical pencil and pad of paper? Do you use a text editor to get your ideas and requirements in a bulleted format? Do you use UML?

What my question is, is what's the first step you take when designing a large application? What medium do you use to record your notes? And when are you typically content to start writing code?

share|improve this question
add comment

4 Answers

up vote 2 down vote accepted

My first step is normally to think about the entities in my domain, and how they relate.

I usually start with Excel, with some hierarchy of enities and rough notes on props and methods. Occasionally I'll start with paper, or whiteboard.

Then, I move straight into my DB designer (be it SSMS or Workbench) and start laying the tiles, so to speak. I've dabbled with various modelling environments, but I tend to prefer simplicity, and working directly with a DB.

I like to start writing code as soon as I have a working domain model, because it helps draw out the flaws and sculpt the design (I subscribe to Agile, and TDD). That said, I also pause every now and then to document, by diagram or plain English, my understanding of the model at the time, mostly to communicate with the stakeholders.

Good luck with your next (big) project!

share|improve this answer
add comment

Apple has a page on App Design Strategies that's probably pretty good advice no matter what platform you're designing for. The very first thing on the list is to create an "application definition statement", defined as:

a concise, concrete declaration of an app’s main purpose and its intended audience.

share|improve this answer
add comment

pen, paper, text editor, mail and as much face to face with the client as I can.

always try to do a high-level (abstract) design session with the client where you give him papers so he can draw windows, bubbles, lines, schema, whatever... then come back home and immediately (this is important) redraw or assess them using whatever tool you know, which can just be a new and clean sheet of paper.

rewriting the spec when you head will have cleared helps you find parts of the spec which aren't clear, seem redundant or illogical. From that point on, your questions to the client should start being very specific and improve.

When possible, I also try to prototype in this early design session(s), using the REBOL language for its capability to build interface and object prototypes right in front of the client. I can usually pop up an interface mock-up, just as he's finished talking to me (I can type REBOL code with my eyes closed ;-).

Its a very succinct language and its use of DSLs and almost natural language syntax and file format are very effective at describing things and data which the client will actually be able to read right of your text editor!

Here is a complete gui mock-up application which opens a user creation window and a simple confirm dialogue, example:

rebol []

user: make object! [
    first-name: "John"
    last-name: "Doe"
]

view gui: layout [
    text "first name" 
    field user/first-name

    text "last name"
    field user/last-name

    btn "create" [view layout [text "User was added" btn "close" [unview]]]
]

no need for abysmal XML syntax and complex IDEs which just make the screen look like a total science lab to your client..

for each little topic, you then build one of these little tiny apps and they become an implementation reference. (you can even save any gui to disk as a png using one line of code!:

save/png %user-creation.png to-image gui

which you can easily send to your client for reference and approval too.

hope this helps.

share|improve this answer
add comment

Here's my entire workflow, not just pre-coding, but decided to include the rest for completeness :)

I've just started building my own workflow for personal projects, but here 'goes:

  • Executive Summary: What is my application in a nutshell? This helps to keep me from getting sidetracked during development: Does this feature I'm thinking about belong in my application based on my summary?
  • Case Studies: Are there any applications out there that do anything similar to what you're planning on doing? What can you learn from them? What do you like? What don't you like? How will you fix those things that you don't like?
  • Wireframes: I've been using Pencil and have been loving it. This is basically the step where I figure out most of the requirements for my models. It allows me to build a click-through of my application without having to code anything.
  • UML: Based on the wireframes, I have a pretty solid idea of what models I'm going to need to build and what business logic I'm going to need to write. UML just allows me to flush it all out prior to coding anything.
  • Prototype: Write something fairly quick and dirty to prove out all functionality in my application. This will not have any graphics or styling applied to it. It's functional only
  • Final Application: The prototype shouldn't be throw-away work, so I can just refactor some of the code, apply styling/graphics/script to it..
  • Testing/Bug Tracking/Bug Fixing

And I'm done.

Yes, there are a few steps here, but I find it really valuable when developing large scale applications.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.