Use of low tech tools when it comes to programming [modified]
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
Word for functional design and brainstorming, and Visio for UI design, along with small test projects in VS if I want to test the feasibility of a specific library or code model I'm considering using. I also scrapbook using OneNote and collect links using Surfulater. There are benefits to be had when using pen and paper for diagramming, that Visio doesn't have, but to me the hassle of maintaining and carrying around a bunch of physical pages isn't worth it. Anything on my laptop stays where I initially put it, is with me wherever I travel with effectively zero extra overhead, is backed up when I run my backup routines, and can be transferred to my smartphone with a few clicks as well.
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
whiteboard for the design, pen and paper for neatness (ref), visio/balsamiq for the UI, then VS
Life - Dreams = Job TheCardinal BenPOS Systems
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
Thinking through logic I tend toward pen and paper. Probably a bit excessively. I also tend to sketch out the GUIs on a pad of paper as well, sometimes adding colored pens to work on the details. Working out architecture, complex systems, integration and, deployment I use a big portable whiteboard that I got myself a couple of years ago that allows me to print out the good stuff. This I have found saves some time since I can just scan it to a pdf and keep it rather than having to recreate it with a diagraming tool. I usually don't start writing code until I have a decent idea of exactly what I want to accomplish.
Sovereign ingredient for a happy marriage: Pay cash or do without. Interest charges not only eat up a household budget; awareness of debt eats up domestic felicity. --Lazarus Long Avoid the crowd. Do your own thinking independently. Be the chess player, not the chess piece. --Ralph Charell
-
Thinking through logic I tend toward pen and paper. Probably a bit excessively. I also tend to sketch out the GUIs on a pad of paper as well, sometimes adding colored pens to work on the details. Working out architecture, complex systems, integration and, deployment I use a big portable whiteboard that I got myself a couple of years ago that allows me to print out the good stuff. This I have found saves some time since I can just scan it to a pdf and keep it rather than having to recreate it with a diagraming tool. I usually don't start writing code until I have a decent idea of exactly what I want to accomplish.
Sovereign ingredient for a happy marriage: Pay cash or do without. Interest charges not only eat up a household budget; awareness of debt eats up domestic felicity. --Lazarus Long Avoid the crowd. Do your own thinking independently. Be the chess player, not the chess piece. --Ralph Charell
Chris Austin wrote:
I usually don't start writing code until I have a decent idea of exactly what I want to accomplish.
Exactly... you aren't in college any more!! Create assignment-->reverse engineer design!
I don't have ADHD, I have ADOS... Attention Deficit oooh SHINY!! Booger Mobile (n) - A bright green 1964 Ford Falcon - our entry into the Camp Quality esCarpade!! Do something wonderful - make a donation to Camp Quality today!!
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
I am like you - a HUGE fan of pen and paper. In fact, I overuse them; I am trying to use Scite/Excel more so I can mail my findings to somebody else directly. Just a suggestion for the paper users here - use the reverse of old single-side printouts. There is no dearth of documents printed but never picked up at my place. :(
Cheers, Vikram. (Proud to have finally cracked a CCC!)
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
Personally I prefer a beer coaster, under duress I will move to the menu blackboard but that tends to piss off the cook so I try not to do that too often. Note, collating and drying the beer coasters the next day is a critical point in the development cycle and should not be attempted before an excellent coffee has been consumed.
-
I am like you - a HUGE fan of pen and paper. In fact, I overuse them; I am trying to use Scite/Excel more so I can mail my findings to somebody else directly. Just a suggestion for the paper users here - use the reverse of old single-side printouts. There is no dearth of documents printed but never picked up at my place. :(
Cheers, Vikram. (Proud to have finally cracked a CCC!)
The problem with paper is that it has a great propensity to get lost exactly when you need it :). Like you, I usually use the backside of printouts, which doesn't help.
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
Hi Sri Rama-ji, I really appreciate your posts, like this one, on the Lounge that invite open-ended, interesting, technical discussions. From this one I've made a mental note to go see whatever happened to Visio (which I haven't looked at for years). Personally, I switch between "modes" as I work : when I feel "stuck" conceptually in the "big picture," I switch to prototyping some small piece, or utility application, of the "problem-space," focusing my mind on the code, and often that re-direction of focus seems to allow my "unconscious mind" to come up with some idea that then ... takes me back to the big picture ... Or I leave the room where I normally program (at home), go lie on the bed with a notepad and pencil and diagram. I used to enjoy using a big whiteboard when I worked for companies. For me knowing when to "bear down" and keep up concentration, and when to "let up" and shift modes, seems like an "art." That said, I do think programmers often have certain types of "professional temperaments" : some are, by nature, strongly top-down analytic types most comfortable with formalizing the "big picture" first using design patterns, etc., or focusing on working out the "key algorithms" and data structures (or data access layers and mechanisms) first ... others (I think I'm one) are, by nature, more "bottom up," needing to get busy coding, and then cycle back and forth between prototyping and design. But, at this point, I'm just an old dilettante, doing this for "fun" :) best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
-
The problem with paper is that it has a great propensity to get lost exactly when you need it :). Like you, I usually use the backside of printouts, which doesn't help.
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
I have my own drawer, and I can find my stuff with no problem.
Cheers, Vikram. (Proud to have finally cracked a CCC!)
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
For me, pen and paper is a waste of time and trees. I achieve exactly the same result 'sketching' out a high-level design in VS, with the benefit of visible results. When my design works, I fill in the details. I have, however, been doing this on and off for 20 years, and full time for 10, but my latest endeavour, web design[^], would be in the gutter if I had to use anything except VS first. PS, that page is barely functional, not an example of best effort, which will only be available this afternoon.
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
Whiteboard: A whiteboard helps me thinking and explaining. It's a bit quirky maybe, but works well. Post-its: 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. pen-and-paper: To-Do list on crazy days. I have a thin A5 ringbook that I use to put things into order of execution when I get ten issues with "top priority". I also use it to jot dowen notes, and do some minor design. I don't use it daily, though.
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist -
I agree. I tend to start a complex task by working in the garden the weekends before I start it. I'll think it through before I start in VS. I do find that sticking to VS when stuck can be a trap. If I have to run an errand, thinking about it in the car often leads to a better solution than the direction I was taking. I'm not saying I need to do this often, but when something becomes non trival and a road block, I'd solve it by walking away, and doing something physical, like a swim or digging the garden for 15 minutes. Usually that's long enough for me to think it through and come back and solve it in no time.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
Christian Graus wrote:
digging the garden
Your garden is full of holes then right? :)
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
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
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
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.
-
whiteboard for the design, pen and paper for neatness (ref), visio/balsamiq for the UI, then VS
Life - Dreams = Job TheCardinal BenPOS Systems
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
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
-
What role do post-its, pen and paper, and whiteboards play in your day to day programming tasks? One of the thing I have found in programmers, and also other professionals, is the attitude of jumping straight to a computer software application to solve a problem. For example, presentations are almost invariably started in powerpoint rather than on pen and paper. Programmers start working directly in Visual Studio (or tool of choice) as opposed to working out the logic first on pen and paper (or whiteboards). I will not say that pen and paper method is efficient in all the cases. But I do think that complex problems are best handled with pen and paper first and then in the IDE. I have found myself wasting lot of time on trying to get some piece of logic work through editing and debugging cycle. Eventually, when I slow down and use pen and paper, I find that the problem gets solved faster. I have a feeling that, if the amount of time which developers spend on computer is capped then they will perform better. For example, once a task is assigned to a developer he should not be allowed to work on the computer directly till he comes with a plan or design on plain paper. I wonder if such a thing will work in practice. So what technique do you normally follow: solve the problem on pen and paper followed by IDE or try IDE first and if the problem turns out to be too complex jump to pen and paper (or may be not at all). Do you have a preference (habit) either way?
modified on Thursday, August 27, 2009 12:29 PM
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.
-
Christian Graus wrote:
digging the garden
Your garden is full of holes then right? :)