How do you put your ideas together?

[P1X3]

Go!

[Muffinator]

Double sided tape.

[zahlio]

Well, i try to write basics down on a sheet of paper. I then maybe code some stuff to see if it is worth anything. 

 

If the project evolves i use http://asana.com/ + bitbucket.

[TechTheWorld]

I just build it.

[P1X3]

Well, i try to write basics down on a sheet of paper. I then maybe code some stuff to see if it is worth anything. 

 

If the project evolves i use http://asana.com/ + bitbucket.

What kind of stuff you write down on paper?

 

I have been writing down stuff from something specific (struct/class) to something really broad.

However I can't see a way to put all of that together, so I created this topic to see how other people do this.

[alpenwasser]

It depends a bit on how the project looks (complexity) and how much time I have, but

for something complex I usually draw from my army days (I'm aware you don't need to

go to the army to learn this or similar sort of techniques, but that's where I learnt

it):

• Assess situation.
• Define objective.
• Formulate plan.
• Execute.
• Assess result, if required repeat process until result satisfactory.

This I iterate over different levels of detail during the project's time. For example

if I want to write a program that outputs user input back to the console, the process

would look something like:

• I'm in a command line environment, O/S is UNIX-like.
• I need to take user input and write it back.
• Look up what functions I need in order to achieve that, stitch them together.
• Write program, compile.
• Check result. If buggy, go back and fix.

It might look a bit stupid and overly complex for a program this simple, but for

larger things (not just when it comes to programming) it's really quite a handy

technique, and nowadays I use it even without consciously thinking about the steps.

It has become my natural process of thought for solving problems in most cases.

So, even when I just start doing things a bit more chaotically, the process will

naturally more or less adhere to this outline. I usually don't consciously sit

down and write out all the answers to this technique's questions, it's just the

normal process my brain works through to get to the result.

Of course, thinking needs to be flexible and adaptive, so when my thoughts take

me somewhere else I will often follow that train of thought for a while and just

see where it leads me, especially when the problem requires more creativity than

strictly adhering to bullet points. ;)

[zahlio]

What kind of stuff you write down on paper?

 

I have been writing down stuff from something specific (struct/class) to something really broad.

However I can't see a way to put all of that together, so I created this topic to see how other people do this.

Well i dont write any code down on paper. I write down ideas and things i wish to implement.

[Flojer0]

I will note that aside from a good computer I believe that a white board (or more :P ) are a programmers best investment.

 

I usually start with a flow chart to give me an idea of how I want my program to be laid out. Then I dig down as pseudo code with method calls and the like. If it is still too abstract I'll draw more charts and dig until I feel I've reached bottom. At this point coding is usually pretty hassle free, but I do  have to go back and re-do some ideas because I didn't dig down enough.

[Darkfeign]

Hurray for whiteboards. Just plan out methods and their inputs and outputs, and it should start coming together.

[alpenwasser]

I have two huge windows in my room. For my next project I think I'll go buy some whiteboard

markers and put that glass to some good use :D

[Flojer0]

I have two huge windows in my room. For my next project I think I'll go buy some whiteboard

markers and put that glass to some good use :D

I very seriously considered that idea. But I was worried of the w.a.f. (wife approval factor) of doing such a thing. though it would keep the windows clean. :P

[Cheesebaron]

I just start coding :D 

[alpenwasser]

I very seriously considered that idea. But I was worried of the w.a.f. (wife approval factor) of doing such a thing. though it would keep the windows clean. :P

Ah yes, that is of course something I don't have to take into consideration. Whether or

not that's a good thing or not I'm not so sure. :D

[MikeD]

I have two huge windows in my room. For my next project I think I'll go buy some whiteboard

markers and put that glass to some good use :D

 

My neighbors would think I was insane, but I still have a school I can go to with whiteboards I can use!

 

But yes, drawing is the best way to get our ideas together. After you know how entities on your project communicate and interact (you can use component and connector views for this) you can start drawing and scribbling more specific algorithms (pseudocode). Drawing time charts can also help you consider all the possible scenarios (e.g. if you are using a client-server architecture that requires tracking client requests, to prevent some from being executed twice for example, you can simulate messages being lost or reordered). Or, if you are writing a parser for a compiler you can write an input example and see how your compiler would build the syntax tree. Or if you are doing some part of a project that holds state you can draw state machines and simulate state changes and corresponding messages. The possibilities are endless!

 

You should also specify the architecture of your project in terms of modules. Are you going to divide your code in layers (for instance to separate app logic from networking), are you going to use is-a relationships in your modules (usually observed in OOP but possible elsewhere), ...? Again, there are lots of things to think about when writing code, even more so in large projects.

 

And when you start coding begin with the basics and add functionality. For example, if your code is divided in layers start coding from the bottom up. And build skeletons before you start filling in details in some parts and later having to rewrite the whole thing because you forgot a little detail. This way, after you have basic blocks of code that can communicate with each other (for instance if you are building distributed applications) you can fill in with the functions that will start making useful things happen! And maybe while you do this you start seeing things that you may not have been aware of, be they restrictions from the language that you chose or aspects of the problem you overlooked, and you can easily change your solution.

 

Software architecture is actually an area of computer science worth exploring because knowing how to structure our code and the entities of the application makes it very easy to get our project working and can avoid many problems later in the development cycle. And most of the problems we are trying to solve have already been solved, so we can learn from other's projects to know if a certain architecture works for our particular problem. Also, following some architectural guides can make it easier for you to correct mistakes or change functionality later without breaking the whole project, because programming is not without it's surprises!

 

The AOSA (Architecture of Open Source Applications) books are interesting to read because they explain the architecture decisions behind some well know open source applications and how those architectures influenced the project. In class we studied the The Glasgow Haskell Compiler, nginx, ZeroMQ and Graphite applications but I am sure the others are also interesting (some may be a bit boring though, and there is one chapter about the game Battle For Wesnoth!). The Scalable Web Architecture and Distributed Systems chapter is also an interesting read for those interested in Distributed Systems (like me!). Note how each author explains their architecture without requiring almost any code examples. This means that building an app often is not programming language dependent, at least in the first phases. Another good book is "Software Architecture in Practice , Len Bass, Paul Clements, Rick Kazman, 2003, Addison-Wesley" which is technically the recommended bibliography of my SA course (but I studied by the slides!).

[Assume]

Personally I started by writing methods that will apply throughout the program. I try to write as much as possible so as I'm writing the part of the program that user actually interacts with I won't have to go back and write code that may break my concentration on what I was previously doing.