For programmers: plan it all out first, or just start coding?

[retorick]

I believe I've read and heard that the proper way to program is to write out your requirements, develop flow charts, document the code you expect to produce, and then start coding.

I've NEVER worked this way, and the evidence suggests that the programmers with whom I've been most recently associated don't work this way either.

When I recently started becoming familiar with the eight functions that go with the 16 types, I saw that Ti is strongest in INTP and that Te, by contrast, seems to go for charts, graphs, schedules, organizing and categorizing, etc. I also read that an exercise to get oneself into a Te mindset is to find a task (an example was washing the dishes) and instead of simply launching into it and getting it done, mentally go through each step and name and describe it out loud. (You've got to be kidding, right?!)

Since this is a Te approach and INTPs instead introvert thinking as their primary function, I'm wondering if INTP programmers in general don't see much point in planning out their coding, making flowcharts, writing up the documentation, etc.? At least, not in advance. I should infer that the INTJs would be much more inclined to do this.

Then, too, there's the problem of providing estimates: the perennial question of, "How long is this going to take you to do?" Well I'm sorry, but how the heck do I know how long it's going to take? I don't even yet know the details of how I'm going to write the code, what unexpected barriers I'm going to encounter along the way, etc. I *might* know how long it'll take once I'm done. I don't know: give it a week or two.

 

[Hawkeye]

When I wrote my programs I did like you say 'plan' on the fly. I only did this because if I started a plan at the beginning I'd probably spend hours perfecting it instead of actually coding. So to trick myself I don't plan. It gets the work done but has it's drawbacks such as you don't know when you'll be finished or what parts you should focus on next.

Generally my codes were 'messier' than my collegues but just as efficient.

 

[Felan]

I usually do initial planning, most particularly for virgin code as opposed to withered code.

I spend a good deal of time understanding the data and requirements. Sometimes I'm the one that has to gather the requirements and sometimes I'm not. I like having good requirements as it tends to focus my efforts so I don't get as distracted by all the what-ifs.

After I'm comfortable with the data and requirements, I will more or less sketch out a model of some abstractions for the code. This can occur as I "start" writing, but really its rare for any of my first bits of code to survive long. The model is refined by the code which is refined by the model.

Design at the start saves so much time at the end. I've only really managed clean maintainable code (the most important virtue to me), when I put substantial effort in the design first. A side benefit of cleaner code is that performance usually benefits from it and even I have to tweak something it has been easier to address.

I shudder when thinking of the days when I would just jump in and start coding. Still have nightmares of it. The first round usually works well enough. Its the tweaks and additions after that are just absolutely hellish.

 

[Huh!?!]

This made me chuckle.

I agree whole-hearted with you that INTP's are not geared towards the whole estimating, planning out & definitely not the documentation aspect of programmimg.

However, bitter experience taught me a few things ...

- I got in the habit of jotting down the logic of tricky code so as not to tie myself in knots if I thought of a more efficient way of doing things half way though (not that I could always read the scrawl)

- when providing estimates, usually the thing that you think is just a quick & easy job isn't. Whatever you do don't tell the business that it's quick cos you'll only shoot yourself in the foot & nearly kill yourself getting it done in time so as not to look like an idiot!

- I found that when estimating it was generally better to 'just' exceed or hit expectation rather than completely trounce them. For example, if I thought something was gonna take 4 days (based on hunches & only later experience), I'd quote maybe 5, and then they'd be pleasantly surprised when they got it early. Similarly, if it actually only took 1 day I might hang onto the code for a day or 2 before delivering so as not disappoint with innaccurate estimates.

- everyone knows documenting code is the devil's work, it's immediately out of date.

Seemed to have worked for me.

 

[fullerene]

I should preface this with "I'm not a programmer"... but I've taken two semesters of programming classes in java, and have experience in python, VBasic, and APL as well.

I've never planned anything out or done flow charts or whatever else either, and my code is usually a lot cleaner and more readable than other peoples'. Even the things that professors said "draw a picture!" for, such as removing a node from a doubly-linked list, makes me go "why? The only rule you have to follow is 'don't break a reference-link if it's your only one,' and everything falls out naturally from that." The only thing that I've found pictures seriously help for is on tests, when they would ask us what the array looks like if you remove three elements during a heap-sort or something. There, drawing out the heap during each step helps me considerably.

out of curiosity, what do you do, as a programmer? I'm a physics major (computational physics, though, so it requires a lot of programming on-the-side), who will probably minor in computer science...but I have to admit that idea of a job you can do at home and move around freely during is extremely appealing to me. The only real problem is that I have no idea what jobs are out there for programmers, or what they're really like, or anything like that. What's the job like on a day-to-day basis, and how hard to the bosses drive you?

 

[Juno]

I try to plan my work then work my plan. It's less implementation time, less stress, and in the end less bullshit to troubleshoot.

 

[Artifice Orisit]

Step 1: Write down objectives on scrap paper & maybe doodle a bit.
Step 2: Go get a coffee.
Step 3: Come back and refine doodle.
Step 4: Stare at the wall for 5min.
Step 5: Write Code.

I like to have all my thinking done before step 5, so I can just relax.

 

[ChristopherL]

psuedocode then flowchart then start writing.

Comment alot.
Using obvious variable names.

 

[meshram.alok]

Brilliant Thread. Something that keeps on tusseling in my head. I'm a very messy coder usually, and since I'm still a college student, I don't think that's pretty much of a problem now; But I think it might be later, as I'm joining a Software firm.

What I hate about planning out code is that coding then becomes a mechanical and mindless task. I code a lot, and I usually get brilliant ideas in between my coding. They're usually fun to do and innovative. This does not happen when I plan my code out in advance, because then I feel like being "bound by shackles".

In any case, Sometimes I get so Intuitive during programming (especially when I've been coding a lot) that structures and flowcharts pop up in my head as I go along. I kind of visualise the various entities in my code and the connections between them in my head as "black boxes". I love this mode of mine as brilliantly clean and efficient code results.

I'd rather make a rudimentary structure rather than a flowchart/plan. It leaves a lot to innovation and new ideas.

 

[Concojones]

I'm not a professional coder but we used to do coding at university.

What I used to do is make a rough overview on paper, and refine as I code (look at it as drilling down). So yes I always have a great overview of where I am and what is left to do - I like it that way. It also helps prevent bugs (I'm an absent-minded 'professor', plenty of bugs in my code, and I hate debugging). I admit I don't like writing out every detail on paper in advance, so I do that as I program (one 'module' at a time). I really do a lot on paper - for some reason I concentrate a lot better on paper, making less mistakes (the dreaded bugs).

My time estimates are always WAY too optimistic, so keep a huge margin of safety.

 

[Felan]

out of curiosity, what do you do, as a programmer? I'm a physics major (computational physics, though, so it requires a lot of programming on-the-side), who will probably minor in computer science...but I have to admit that idea of a job you can do at home and move around freely during is extremely appealing to me. The only real problem is that I have no idea what jobs are out there for programmers, or what they're really like, or anything like that. What's the job like on a day-to-day basis, and how hard to the bosses drive you?

I've been programming professionally for nine years now. Before that I did odd programming jobs here or there.

I work from home on occassion, but not often enough. My work day is largely spent in my brownish-gray cubicle.

Some in the field work more or even exclusively from home, though I suspect vast majority have cubicles or are stuffed into empty closets/storage rooms.

As with any job there are good days and bad days. I enjoy my job more than any other I've had. When things are good its like poetry in code, when it sucks its like data entry.

Some days it seems all the work you get is changing some links on a web page, which annoys the hell out of me. Even worse is the procedures we follow for changing a link on a web page is essentially the same as we build a project from scratch.

I am often tasked with gathering requirements and I actually do enjoy it to an extent, sometimes even prefer it. Too often they have this idea of what you can do that is totally whacked, they don't say things they want because they think its too hard but the work arounds they come up with to make my life easier does quite the opposite.

Once I'm done with a meatier project I usually really excited to turn it over to the Business Unit. I always hope they are thrilled, often they are. One thing I try hard to not do is show irritation at things like font, color, and spacing changes. I don't really understand why they fixate on those things so much but they are great for being to say yes to without hesitation. Saying yes a lot makes saying no when it counts much easier.

I put in anywhere from 40 hours to 70 hours a week, with the mean around 45 hours. I don't get paged too often after hours.

If there are any specific questions I'd be happy to answer them in forum or PM. I love my job.

 

[ChristopherL]

Brilliant Thread. Something that keeps on tusseling in my head. I'm a very messy coder usually, and since I'm still a college student, I don't think that's pretty much of a problem now; But I think it might be later, as I'm joining a Software firm.

What I hate about planning out code is that coding then becomes a mechanical and mindless task. I code a lot, and I usually get brilliant ideas in between my coding. They're usually fun to do and innovative. This does not happen when I plan my code out in advance, because then I feel like being "bound by shackles".

In any case, Sometimes I get so Intuitive during programming (especially when I've been coding a lot) that structures and flowcharts pop up in my head as I go along. I kind of visualise the various entities in my code and the connections between them in my head as "black boxes". I love this mode of mine as brilliantly clean and efficient code results.

I'd rather make a rudimentary structure rather than a flowchart/plan. It leaves a lot to innovation and new ideas.

Until it becomes unmanageable.

 

[Oblivious]

I seem to intuitively know how to implement the structure of my code, so I do not really put much thought into it. I just develop the arms and legs of it and sew the thing together in the main, which is usually just a bunch of function calls and data initialisation.

Its not so much flowcharts and procedure as it is how the parts of my code interact with each other.

 

[fullerene]

thanks a lot, felan!

um.... I guess I would have to ask, does it seem like all the programming jobs require website skills? I have very, very little knowledge of html (although I can, sometimes, figure out what to do by reading the code and looking for patterns. I could chanage the reference of a link, for instance, or the color of font, or extend a chart one level--but not create a new chart, for instance). Do you have a program like dreamweaver to help you out, or do you have to change the source directly?

Also, 70 hours a week is a lot of time. Is the amount of time you spend predictable? Did you choose to work 70 hours that week, or did they just overload you with so much work that you had to? I know I can put in 70 hours a week--I did it actually a week or two ago while writing up an entry for an APL competition--but it made me a little sick of being around a computer for a few days after. I guess... it just seems like, if they can suddenly ask you to put in a 70 hour week, then they could very easily "inch up" the amount of work they want you to do and run you into the ground after a few years. Has this been a problem so far, or do you have any way of defending yourself if it starts to become one?

Also: you mentioned procedures that you had to follow when changing the link on the webpage, the same as everything else. What kinds of things did you have to do?

 

[Felan]

thanks a lot, felan!?

Welcome.

um.... I guess I would have to ask, does it seem like all the programming jobs require website skills? I have very, very little knowledge of html (although I can, sometimes, figure out what to do by reading the code and looking for patterns. I could chanage the reference of a link, for instance, or the color of font, or extend a chart one level--but not create a new chart, for instance). Do you have a program like dreamweaver to help you out, or do you have to change the source directly?

I would consider good website skills pretty essentially to most programming jobs. The vast majority of the work I do and know is being done is web-related. Tools will do varying amounts of the html side of things for you. I have yet to use a tool that let me get away from working with the html. Consequently I would consider HTML a pretty fundamental technology along with Javascript. There are a number of server side web technologies that work great, getting good with one of them is pretty essential, I'm most familiar with ASP.NET. Finally learning a reasonable amount of SQL and database design is important, any particular variety of SQL is fine.

Also, 70 hours a week is a lot of time. Is the amount of time you spend predictable? Did you choose to work 70 hours that week, or did they just overload you with so much work that you had to? I know I can put in 70 hours a week--I did it actually a week or two ago while writing up an entry for an APL competition--but it made me a little sick of being around a computer for a few days after. I guess... it just seems like, if they can suddenly ask you to put in a 70 hour week, then they could very easily "inch up" the amount of work they want you to do and run you into the ground after a few years. Has this been a problem so far, or do you have any way of defending yourself if it starts to become one?

I usually push myself to work the longer hours and I don't do it often. Usually near the end of a project for one or two weeks and I've only done it 2 to 4 times a year. I couldn't do it if it was all the time. In general I put in 45 hours a week. The typical day has a lot of flexible time.

I'm just turned over a project to QA today and I put in a lot of hours to finish it up. I was handed the project with pretty well detailed requirements. I spent a couple of days looking over the requirements and the existing code and then made my estimate. I didn't get it quite done in the time frame I expected and worked to get it done as close to on time as I could. I told myself to do it before anyone else did.

Also: you mentioned procedures that you had to follow when changing the link on the webpage, the same as everything else. What kinds of things did you have to do?

We use the waterfall methodology at work. I would prefer an agile methodology but its not my call.

The main documents that get written are Test documentation, Business Requirements Documents, Technical Design Documents, and Code Publication documents. Some of them we can skip (for smaller things like links) but they are asking us to write more of them. There are also a bunch of communication templates we have to send out as a project moves through stages.

 

[QSR]

Ah Felan, good to hear your perspective on this. I've been a QA tester for 9 years, so I have a somewhat different view of things, especially since I've learned how software should be developed in contrast to what most of my experiences have been. Waterfall is a pretty dysfunctional way to operate, and you've just touched on some of the reasons why. You get requirements, spend 2 days trying to estimate how long it's going to take; you hope the business unit is happy with what you get; you hand things off to QA as though they belong to some totally separate organization.

Agile has some big advantages over this. The problem is that when we start to create a program, the truth is that the job is more complex than anyone can understand by simply looking at some requirements. You find things out as you go along, and external pressures change your requirements while you do the coding. The result is that your estimates are terrible, QA gets squeezed to the point that the testing is just a token at the end, and the software doesn't meet the new marketing requirements by the time it is delivered. The result is that you have to go back and try to build on code that is of questionable quality to begin with, your technical debt builds up, and your code starts heading down the road to unprofitability.

But--for those of you who are just learning how to code--I recommend you learn test-driven development. It basically means you have to understand the requirements well enough to write tests that the code must pass before you can even start the more challenging user tests (aka QA). TDD is a good way to avoid technical debt. Sometimes you'll code something a certain way, then find that it needs to be changed later. If you have tests to ensure it still works, you can make changes to the code and not create hard to find bugs. It takes a little bit of time up front, but it's a good idea if you are trying to make a code base that will be around for a while. It's also a good way to avoid surprises when you start coding.

 

[Felan]

Ah Felan, good to hear your perspective on this. I've been a QA tester for 9 years, so I have a somewhat different view of things, especially since I've learned how software should be developed in contrast to what most of my experiences have been. Waterfall is a pretty dysfunctional way to operate, and you've just touched on some of the reasons why. You get requirements, spend 2 days trying to estimate how long it's going to take; you hope the business unit is happy with what you get; you hand things off to QA as though they belong to some totally separate organization.

There situations where the waterfall method is a better choice than agile. I haven't worked in any of those situations yet, but most of the agile advocates I've read will bregrudge waterfall its place. Its just that the waterfall method is like a dump truck when for most development you need a wheelbarrow.

Agile has some big advantages over this. The problem is that when we start to create a program, the truth is that the job is more complex than anyone can understand by simply looking at some requirements. You find things out as you go along, and external pressures change your requirements while you do the coding. The result is that your estimates are terrible, QA gets squeezed to the point that the testing is just a token at the end, and the software doesn't meet the new marketing requirements by the time it is delivered. The result is that you have to go back and try to build on code that is of questionable quality to begin with, your technical debt builds up, and your code starts heading down the road to unprofitability.

But--for those of you who are just learning how to code--I recommend you learn test-driven development. It basically means you have to understand the requirements well enough to write tests that the code must pass before you can even start the more challenging user tests (aka QA). TDD is a good way to avoid technical debt. Sometimes you'll code something a certain way, then find that it needs to be changed later. If you have tests to ensure it still works, you can make changes to the code and not create hard to find bugs. It takes a little bit of time up front, but it's a good idea if you are trying to make a code base that will be around for a while. It's also a good way to avoid surprises when you start coding.

When I first read the second paragraph I saw you talk about Agile having advantages and then dump a bunch of negative stuff and start your next paragraph with TDD. The initial impression of what you were trying to say was that Agile suffers from all the problems you mention and that TDD doesn't suffer those problems. I know you were talking about the problems of using the dump truck of waterfall on smaller projects. TDD is one of many tools under the umbrella of Agile.

TDD is absolutely a great technique/methodology for anyone (not just new programmers) to learn, but trying to applying it to every task is just as bad as trying to apply waterfall to everything. For example if you are the only doing TDD on the team it is a fruitless endeavor.

Also I'm how great learning TDD would be for a beginning programmer ... it would be interesting to see the results of a university course run with one or more Agile methodologies from the start.

 

[QSR]

There situations where the waterfall method is a better choice than agile. I haven't worked in any of those situations yet, but most of the agile advocates I've read will bregrudge waterfall its place. Its just that the waterfall method is like a dump truck when for most development you need a wheelbarrow.



When I first read the second paragraph I saw you talk about Agile having advantages and then dump a bunch of negative stuff and start your next paragraph with TDD. The initial impression of what you were trying to say was that Agile suffers from all the problems you mention and that TDD doesn't suffer those problems. I know you were talking about the problems of using the dump truck of waterfall on smaller projects. TDD is one of many tools under the umbrella of Agile.

TDD is absolutely a great technique/methodology for anyone (not just new programmers) to learn, but trying to applying it to every task is just as bad as trying to apply waterfall to everything. For example if you are the only doing TDD on the team it is a fruitless endeavor.

Also I'm how great learning TDD would be for a beginning programmer ... it would be interesting to see the results of a university course run with one or more Agile methodologies from the start.

First part: There's situations where waterfall makes upper management more comfortable, but I'm becoming more and more convinced that it is a poor choice for anything but the most rudimentary of programs. Waterfall is a way of giving people who have a command and control fetish a way to think they are in control. Spiral makes a little bit of sense in some situations.

Second part: I'm referring to some of the inherent problems of Waterfall. I don't necessarily believe all the stuff that Agile™ purports is great in all situations. I'm probably more in the Lean school than anything. Anything that encourages early testing and more communication is a wonderful thing IMHO.

I was really only talking about TDD because several people here are learning how to program. It makes sense to learn this, as it will make you worth a lot more $$$$ on the market. I'm not a programmer, so I'm really just repeating what I hear from other people.

 

[Felan]

First part: There's situations where waterfall makes upper management more comfortable, but I'm becoming more and more convinced that it is a poor choice for anything but the most rudimentary of programs. Waterfall is a way of giving people who have a command and control fetish a way to think they are in control. Spiral makes a little bit of sense in some situations.

Second part: I'm referring to some of the inherent problems of Waterfall. I don't necessarily believe all the stuff that Agile™ purports is great in all situations. I'm probably more in the Lean school than anything. Anything that encourages early testing and more communication is a wonderful thing IMHO.

I was really only talking about TDD because several people here are learning how to program. It makes sense to learn this, as it will make you worth a lot more $$$$ on the market. I'm not a programmer, so I'm really just repeating what I hear from other people.

I could be wrong but I think we are agreeing that waterfall is too widely used for too many problems. Its a horrible horrible choice for rudimentary programs. Its a very good choice for very large and/or critical programs. Basically in situations where you don't do anything until you know exactly what you are going to do.

Agile is a toolbox and TDD a tool in that toolbox. I'm not aware of Agile being trademarked.

In order to use TDD effectively you need to understand how to code and more importantly how to design the program. Design patterns can help with this but I think it would be hard to learn it holistically at the start, unless you were taking a course that designed for this.

A specific and very common example to TDD is the repository pattern. In essence you abstract how you get your data to a repository interface. Then you implement concrete versions of that interface to provide you the actual data or service.

You can think of an interface like the plug that goes into the wall for power. When you plug in your computer you don't need to know where the comes from or what its doing and the power company doesn't need to know that you are plugging in your computer. Its just knows when something is plugged its to provide power. So if you plug into a UPS, a generator, or the powergrid it all works.

Similiarly with a repository pattern you worry about the interface or shape of the plug and plug receiver. This way you can easily write an implementation that goes to the database for production but also write an implementation that made uses static xml files (for running your tests). I feel I am very good programmer, but I think if I were just starting out it would have been hard to wrap my head around all of that and code it too.

I agree TDD is great. I think it might be a bit much for people to chew when starting out unless they are in a very good instructor-lead course. I would join in you in encouraging people to explore and gather Agile techniques (which includes TDD) as they get more proficient with programming.

*edit*
I love QA by the way! They are terrific allies in catching the problems so the client doesn't end up freaking out about it.

So I'm sending my unequivocal respect and love to you QA'ers!