Use of low tech tools when it comes to programming [modified]

[Tom Deketelaere]

Christian Graus wrote:

digging the garden

Your garden is full of holes then right? :)

[moon_stick]

I always make notes, designs and task lists on paper before I start touching any electronic development (much to the chagrin of the office manager where I work as he's bought into the whole 'paperless office' concept). I used to start working in code and then refine the idea until it worked but I find that a bit of upfront thinking away from my computer elicits better designs and lowers overall production time.

It definitely isn't definatley

[dazfuller]

It depends, most of the time I'll use a combination of both pen & paper and the computer. I'll sketch out a general system diagram on paper, make notes about some of the finer details and if I need to check that a theory works by hacking a quick-and-dirty app together on the computer. Whiteboards are another great tool I find and a really nice method when working in a group is to get everyone at a whiteboard with post-its and pens as it's easy to move things around, scrub things out and debate some of the issues. It also depends on the size of the problem, if I'm writing a simple app then I'll tend to just get on and do it, for really complicated things I wont even think of starting until I've got it down on paper and then in the middle I'll use something like I described above.

[urbane tiger]

ditto but often preceded with some sort of sketch/mind map/mud map etc using any or all of the following: pens on beer mats, serviettes, napkins or tablecloth fat felt tip pen's on butchers paper, lines drawn in sand with stick, finger on misted train windows, crayon on the inside of windscreens CD Marker pens on old CD's (great for problems involving looping) at each stage take a good look around to see if its already been done, if so then context switch to negotiation/acquisition mode and dust off the wordprocessor on which to compose contract.

"I beseech you, in the bowels of Christ, think it possible you may be mistaken." -- Oliver Cromwell

[Jorgen Sigvardsson]

I have a white board (my very own, and I will kill people who even think they can take it from my office) that I use primarily when I discuss design issues with other folks. Otherwise, I just use pen, paper and ToDoList[^]

-- Kein Mitleid Für Die Mehrheit

[Dave Parker]

If it's complex I might plan it out using a simple text editor or in some cases visio (esp if I'm trying to get the object model right in my head) - I don't really use paper for anything though other than quick notes in meetings as it often gets lost or a drink spilled on it plus my own handwriting is *bad* lol. Generally though if I'm in the middle of coding and something is getting quite complex I'm more likely to just break it down into smaller parts and maybe unit test those smaller parts individually - depends on the situation really.

[Lost User]

And bugs.

Visit http://www.notreadytogiveup.com/[^] and do something special today.

[MrZaggy]

Nothing beats the White-Board for nutting out the initial stuff - sometimes I go to the effort of pencil and paper when I don't have a white-board close at hand, but either way, the pen comes first! Then if the project is anything more complex than a hand full of classes (ie, my 3rd Year CompSci projects are all 4-6 classes), the sketches and class attributes lists will find their way into something like Rational Rose, so you can map the relationships and begin to develop (or verify) the class/method specifications you have come up with (personally, I find this is best done with a few Sequence Diagrams; I just despise Collaboration Diagrams). Then you can just dump out a code framework, with comments, and go from there.. But seriously, going from IDEA to IDE is madness... There needs to be time AWAY from from a keyboard before you get stuck in - its a MAJOR problem I see here at Uni (I had a number of years of 'real-world' experience before coming back to uni); the kids are just not taught how to effectively plan and design; they're taught the syntax and how to use O-O concepts. The White-Board (for me anyway) is the only real place to start...

[ormonds]

Same process every time, start in VS, get it wrong, go back to paper, get it right, start again. Explaining to someone else helps me understand it better - verbalising.

[Stefan_Lang]

Normally, anything new involving more than a single new data structure or class goes to my UML tool first, so I can sort out what the interrelations exactly are before I think about what methods and what data I need, and where. If I'm unsure what the actual objects are, then it's pen and (any kind of) paper first. The big advantage of P&P is that I can pin down concepts, methods, and data that I need without having to identify what type of UML object they would be, or where in my code to put them. Once I have an overview of the elements of the problem, I am ready to move on to the UML tool, or if it's clear enough, even directly to coding. I also often dig through a problem in my head while walking around, even going to the loo occasionally gives my great ideas. There even was an occasion or two where I literally dreamt up a solution to a problem I had (and no, I was not dreaming at the office ;P ). Another way of finding a solution is discussing it with someone else. In 4 out of 5 cases I suddenly see a solution just by going through the effort of trying to explain the heart of the problem to another person. I think just imagining to explain it to someone else would do the same, but in that 1 out of 5 case it is advantageous to have a real person to talk to ;)

[Gary Wheeler]

The most profoundly useful tools are the following: - Two Uniball Micro[^] pens, one in blue, one in green. I've used these pens for 25 years. - Old sample cards. We use 5.5"x8.5" card stock for printing samples (we make commercial ink jet printers). I have a box full of these that have been printed only one one side. The cards are a nice size for outlining ideas, making bullet lists, and so on. I use them to keep track of all of my "number one top priorities". They're small enough to shuffle as needed.

Software Zen: delete this;

[Gary Wheeler]

peterchen wrote:

When I leave the office PC's running overnight, I have to stick a post it "keep running" to it. otherwise, the one closing might shut it down.

If someone touched my PC when I wasn't here, the next thing you would see would be their head on a pike outside my cubicle walls. I have scheduled tasks that run at night to do backups and other sorts of maintenance. I occasionally start builds when I leave.

Software Zen: delete this;

[Rama Krishna Vavilala]

Vikram A Punathambekar wrote:

use the reverse of old single-side printouts.

That's what I also mostly do :). I can throw them away once I have transferred my work to the computer. One thing I want to try is to see scan my writing and scribbling and preserve them.

[Fabio Franco]

I often use pen and paper to solve complex logic problems. I draw, write and make calculations no paper. It's far more efficient than the trial/error solution. Some things aren't as practical as using pen and paper. So, yes, this tool is more than welcome. Works fine with me.

[fred_]

worms?

[PIEBALDconsult]

It depends... easy things can go straight to code. More complex things/relationships I write on paper (or whiteboard when collaborating).

[TRK3]

I think best using a whiteboard. Have a huge one covering one wall of my office. I usually work out whatever I need to on the whiteboard and then leave it there for days while I code it up or document it. At my previous position, the conference room was covered with whiteboards from floor to ceiling -- all four walls. We'd work out whatever we needed to and leave it on a section of the whiteboard for months. It wasn't uncommon for developers to get up from their desk and walk into the conference room in order to refer to the documentation. I prefer getting up and walking around to pulling something up on a screen. If I don't have a whiteboard, I prefer a pen a paper. I can draw anything I want with pen and paper, I'm not limited by what a computer program will allow me to do. Often after I've got it all worked out on paper, I can just sit down and code it without having to refer back to the paper -- and I comment as I code so the code is the documentation. So losing the paper isn't an issue. If I need to communicate the design to someone else, whiteboard is definitely the prefered mode -- and leave it there on the whiteboard until we've got it coded. That might mean covering every wall with a whiteboard, but it's worth it. Only problem is working with developers remotely.... Hmmm... Maybe that's why I have such problem with outsourcing pieces of my projects.

[keozcigisoft]

with VSTS 2010 Visual Studio will be our board! lol cool new features for UML however a nice really big white board is a must always before going for the mouse and keyboard

[Alan Burkhart]

If it's something obvious and simple, I go straight to the IDE and get it over with. If it's more complex... I always sketch it out - rather like a crude flow chart - with all manner of scribbles crammed in. Walk away and think about it. Study my aforementioned hen scratch, then write coherent notes on how the program should flow. This is a habit I picked up in the 80's working with dBase. Once I can visualize it on paper, I begin coding in whatever environment is appropriate.

[rohans84]

very true. I have almost never found my notepad when I need it to refer back. During meetings I alway forget it in the conference room and never find my notes again. Wish I could have google to search for my stuff in the real world too!!!