You can't finalize a design before you start coding

[LB]

It bothers me when people say that before they start writing code they plan it all out on paper first. This is a completely insane statement as it completely contradicts itself.

Let's say you're solving a problem in some language. Maybe you're designing an application in C++. Let's say you plan out the class layout on paper (or iPad, or whatever program you would use to plan out these things). You create the layout as you go and you have to change things when you realize "oops that won't work" or "there's a better way to do that". What you end up with is a thing that has been through a lot of changes and revisions, complete redos, maybe just a mess that happens to work. Then you write the code and it exactly reflects the plan you made.

Now let's look at the guy who does it the wrong way and starts writing code immediately. He's making the same application in the same language as you. First, he starts by writing the general headers of the classes and creating the source files that will make up the application. He creates the setup as he goes and he has to change things when he realises "oops that doesn't work" or "there's a better way to do that". What he ends up with is a thing that has been through a lot of changes and revisions, complete redos, maybe just a mess that happens to work. Then he has the code that exactly reflects the plan he made.

I don't know about you, but I don't see a difference. Either way you have the same problems and same results, does it matter that much that a flow chart or graph on paper is a different level or representation than physically written code? Is it easier to erase lines and text on paper than it is to delete methods in text files? In either case you work outside in, creating the most abstract things before the most concrete things. The representation is different, but thing being represented is the same.

So to me, it does not make sense to say "I drew charts and graphs before I wrote any code". "I wrote declarations and interfaces before I wrote any declarations and interfaces." Does that make sense to you?

What people mean to say is, "I did all the abstract stuff before I wrote the implementations."

As for the topic title, making charts and graphs is, as I see it, the same as coding.

[rapidcoder]

In either case you work outside in, creating the most abstract things before the most concrete things.

In that case you are doing it wrong. You should start with concrete stuff and get the damn thing working as fast as possible. Then build abstractions on top of that. I have never, ever seen a coder or designer, who got the abstract design right without first creating some concrete stuff. Working outside in works fine only on paper. Real coders work inside out.

[Stewbond]

I completely agree with you L B. It's not just code. When I write emails or reports, I can't write out the whole thing on paper first, and starting with just an outline doesn't help either. I start from the begining and see where it takes me.

Going through the exercise of actually implementing what I'm doing gets my mind working on the problems that it really needs to work on. I may go through a few revisions, and start from scratch a few times on a class of code or paragraph of text, but every time I rewrite, the idea of how I want it to look gets more concrete and it's easier/faster to implement this next iteration.

[chrisname]

I don't plan or design my programs, I just write and refactor as I go along. I mostly program for personal enjoyment and I enjoy the actual coding. I do brainstorm, but I rarely write anything down, and when I do, I usually delete it afterwards.

The only real planning I've done is story arcs and character/race descriptions for a game. Even then, I didn't plan the actual code. All I did when I started was make all the classes/hierarchy I needed right away, and then I added more as I needed it. I'm doing the same for the 6502 emulator I'm writing (except it's in C, so there's no classes, and actually no structs at the moment).

[Duthomhas]

When you are working on large and complex systems, you absolutely must do some planning first. Part of planning is a discovery stage, where you do write small programs to poke around the system and test some ideas.

Next, you need to do something of a "draft" design. This can be done either with another tool or the one you intend to implement the final design with. Remember, this is just a testbed to play with the requirements and perform some functional analysis.

Finally, you begin organizing your actual code base. Some of it may already exist, or have been written in your "draft" stage, and some of it will be new.

Throughout these last two steps, and also as a step itself, is testing, to make sure everything behaves correctly both (1) as designed and (2) in the system.

Once you have it up and running, it is time for review and possible revision.


Notice that at no point do you say: "This is exactly how everything will work." We state what the program should do and how it must behave for important parts, but everything beyond that is up for working out the problem. It is an iterative process.


Of course, it really does help if you are familiar with your tools. That is why people only want to hire individuals with experience using the tools. It saves a lot of headache and time (and, hence, money).

[Cubbi]

L B wrote:

Now let's look at the guy who does it the wrong way [...] First, he starts by writing the general headers of the classes

That's where your picture breaks down: if he didn't have a design, how does he know what classes to write?

"I wrote declarations and interfaces before I wrote any declarations and interfaces."

Ah, I see, you equate the expressiveness of "declarations and interfaces" written in terms of some programming language (e.g. C++) in a text file with expressiveness of "lines on paper"

Is it easier to erase lines and text on paper than it is to delete methods in text files?

Yes! A line on a diagram may mean days, weeks, months of work to put together as "methods in text files" - even if you're not writing any executable code. I can erase and redraw dozens of those lines on the whiteboard while going through an early design meeting.

C++ (or other languages) simply has no means to express top-level design concepts, user interactions, real-time timing sequences, etc. Only when you get down to the detailed design, when everything else is examined, approved, and set in stone, that's when you start speaking in terms of class hierarchies and programming interfaces. At that level, UML becomes about as expressive as C++ headers, and in fact, there are tools that convert one to the other.

Granted, most people don't design large systems, so i weakly agree that in most everyday cases, planning it out on paper first is just an exercise, in case your career takes that turn in future.

What he ends up with is a thing that has been through a lot of changes and revisions, complete redos, maybe just a mess that happens to work.

Sounds like open source software :)

[chrisname]

Cubbi wrote:

That's where your picture breaks down: if he didn't have a design, how does he know what classes to write?

Does it count as design if you do it in your head? When I come up with an idea for a project I kind of know straight away what I absolutely need (e.g. for a game or emulator the first thing I write is the main loop), and then I start writing code straight away. If I need something, e.g. a structure or class, or a function or set of functions, I switch to writing that and then go back to where I was.

[Cubbi]

Does it count as design if you do it in your head?

Sure.

[LB]

rapidcoder wrote:

In that case you are doing it wrong. You should start with concrete stuff and get the damn thing working as fast as possible. Then build abstractions on top of that. I have never, ever seen a coder or designer, who got the abstract design right without first creating some concrete stuff. Working outside in works fine only on paper. Real coders work inside out.

Your username is a nice hint; I take it you do lots of fast-paced projects that have to be completed by a nearby deadline? I like working on the stuff that can never officially be considered "finished" :)

chrisname wrote:

I don't plan or design my programs, I just write and refactor as I go along. I mostly program for personal enjoyment and I enjoy the actual coding. I do brainstorm, but I rarely write anything down, and when I do, I usually delete it afterwards.

My passion!

Duoas wrote:

When you are working on large and complex systems, you absolutely must do some planning first. Part of planning is a discovery stage, where you do write small programs to poke around the system and test some ideas.

Yes, along with the rest of your excellent post, it is what I do when I work with a new library. @all The point of my first post is that planning doesn't [always have to] mean writing stuff on paper.

Cubbi wrote:

That's where your picture breaks down: if he didn't have a design, how does he know what classes to write?

ibbuC wrote:

That's where your picture breaks down: if he didn't have a design, how does he know what shapes to draw?

You're asking: how do you know what to write on paper without first writing it on paper?

Cubbi wrote:

Ah, I see, you equate the expressiveness of "declarations and interfaces" written in terms of some programming language (e.g. C++) in a text file with expressiveness of "lines on paper"

I'd like to know why Doxygen does it if its so primitive as to make you condescend me.

Cubbi wrote:

Yes! A line on a diagram may mean days, weeks, months of work to put together as "methods in text files" - even if you're not writing any executable code. I can erase and redraw dozens of those lines on the whiteboard while going through an early design meeting.

What if you're using a good IDE?

Cubbi wrote:

Sounds like open source software :)

Indeed, the best kind of software there is.

chrisname wrote:

When I come up with an idea for a project I kind of know straight away what I absolutely need (e.g. for a game or emulator the first thing I write is the main loop), and then I start writing code straight away. If I need something, e.g. a structure or class, or a function or set of functions, I switch to writing that and then go back to where I was.

Pretty similar what I do, except I usually get side-tracked.

[Cubbi]

L B wrote:

Cubbi wrote:
That's where your picture breaks down: if he didn't have a design, how does he know what classes to write?
ibbuC wrote:
That's where your picture breaks down: if he didn't have a design, how does he know what shapes to draw?

You're missing the point I'm trying to make: for sufficiently complex projects, the gap between what those "shapes" can show and anything that can be written in a C++ header file is intractable.

For small projects, where you're down to classes and interfaces from the start, it isn't a major point, it becomes a matter of style or habit how to handle design communication (or, if you're a one-man team, if you need to communicate your design at all)

I'd like to know why Doxygen does it

I am not following. Doxygen isn't a design tool, it produces "as-built" low-level documentation.

[chrisname]

L B wrote:

When I come up with an idea for a project I kind of know straight away what I absolutely need (e.g. for a game or emulator the first thing I write is the main loop), and then I start writing code straight away. If I need something, e.g. a structure or class, or a function or set of functions, I switch to writing that and then go back to where I was.
Pretty similar what I do, except I usually get side-tracked.

Oh yeah, me too. I rarely finish projects because as soon as I get a significant way into one I think of another cool idea and work on that instead.

The coolest thing I tried to make recently was some kind of post-assembly optimiser. The idea was that in its first phase it would make measurements of the platform, e.g., how many cycles each instruction took, what extensions (FPU, SSE, etc.) were available and so on. Then the second phase would involve reading an executable and changing the code to make it use the extensions as much as possible and try to change some of the instructions to use faster ones. I couldn't even get the first part working, though. I know how to use CPUID to find out the available extensions, but measuring the amount of cycles was too inaccurate, plus modern CPUs are pipelined anyway (instead I should have had it try to figure out what instructions are the most "pipeline-friendly" or something). Still, it was a cool idea, and not something that I've entirely given up on.

[DeXecipher]

Doing it in my head is how im doing my game engine, and i can tell you, its taking a hell of a lot of time, but it works. Now being in college I am exposed to diagramming tools so I'll probrably use those later, but for right now I'm in no rush because I still have a shitload to learn.

[DeXecipher]

Projects don't need diagrams, but they help, as an alternative to UML (before i got exposed to uml) this is how i started my game engine project, simply by listing all the shit i wanted to do.

But before that, i decided my language, what I would be using, Interfaces, Classes, and Templates. AND I defined how I would arrange everything, into namespaces. I copied a few things i saw in Ogre, in terms of ideas and implemented them myself in my own engine. I do not recommend this method, but it gets you going, just putting SOMETHING on paper to refer to. If you dont put anything in writing for something that is a huge project, then you are wasting time and energy, I burned myself out when i first started after my first version got deleted and I had to start all over again.

[LB]

DeXecipher wrote:

listing all the shit i wanted to do.

If only I could do that even. I'd make a lot more progress if I didn't have to memorize what I wanted to do.

[DeXecipher]

@L B
i know what you mean, but think about it this way, at least if you get sidetracked in the complexity of a project, you are doing something that you want or need to get done. Thats why I write almost everything down that i think of in comments on my main header files.

[devonrevenge]

you know what would be good, some beginner advice and disciplin in planing theapplication...a learner has to discoerthings for himself with problem solving however a known way of going about something could give the beginner some good habits...and it may be a bit clearer when you guys look at said beginners code in order to help

[Stewbond]

I'm reading up on UML (unified modeling language). It seems like a good way to work from the top down which eventually turns into code. Has anyone used this?

[Cubbi]

I use UML, more or less.

[LB]

Stewbond wrote:

It seems like a good way to work from the top down which eventually turns into code.

This is what angers me. It is code from the very start, just in a different language that can't be executed by computers. Why do you call it something different?

[cire]

I'm confused. By that logic all languages are code, which doesn't seem like a very useful distinction.