Stop Trying To Code Me And Code Me

TheMatrix "Stop trying to hit me and hit me!" -- Morpheus.

No plan. No working doc. No diagram. No discovery. No nuthin'.

Just code (read, "hack") until it is done.

CowboyCoding, in other words.

Unless, of course, your coding practice includes a healthy dose of OnceAndOnlyOnce, YouArentGonnaNeedIt, and the SimplestThing. I find that making deliberate, but not extreme, efforts to apply the LawOfDemeter also helps keep things on track.

Is this an attempt to criticize MetaCodingActivities??

If those are there because you are too afraid to write the program, then yes.

Can you explain that, please? Why would I be "too afraid" to write the program?

When you actually write the program you have to worry about things like bugs, user requirements, time and cost. It can feel much safer to expound on all the things the program will do and how it will do them than to sit down and make it happen.

In some shops, there is a strong CultureOfBlame which inhibits some developers from sitting down and writing the code for the system under development until everything is specified in enough detail to relieve the programmer of responsibility for failure.

In another case, an inexperienced programmer may lack the confidence to know where to start. The programmer sits, thinks, studies, writes requirements, descriptions, diagrams, etc, in an attempt to gain understanding before starting. This page can be seen as a reminder that writing code is a good way to learn and gain understanding as well. In many cases, it is a better way to learn than those other activities, and it has the advantage that it gets the project closer to done. Writing, reading, talking, and thinking are no substitute for doing the thing.

Personally, I think that a combination of both is the best way. With each new function/method/object... that is written, you may need to sit back and analyze how it fits into the broader system. And besides, some algorithms are easier to write when they have been visualized on paper. Of course, there always comes a time to sit down and write some real code, but thinking about it first may reduce the actual coding time.

What is one doing when "thinking about it"? Trying to play computer and execute fuzzily thought out code in one's head only provides the illusion of benefit. Have a problem that will probably need a complex algorithm as a solution? Attack the problem sequentially. Write a solution for a trivial subset of the problem and verify it works. Iteratively adapt the code to cover more and more of the problem areas (i.e., use TestFirstDesign). Don't worry where a new function/method/object will fit into the broader system, get something to work and then see how the resulting pieces are compatible with other existing pieces (i.e., ReFactor). In other words, the sooner one has something concrete, i.e., working code, the sooner one has something that can be objectively evaluated. It is far more efficient to write and rewrite the code multiple times than trying to perfect it inside one's head and only type it once.

When I read this title I think AnalysisParalysis as TryingToCodeMe. CodeMe? SpikeSolution.

See also YouThinkThatsCodeYoureWriting.