0

Whenever I work on some fairly significant piece of code, often I find that the I go through a phase of high level designing (aside: I like to use pencil and paper for this), followed by mental walkthroughs to highlight flaws and make refinements.

I see coding as another level (and finest grained) of mental walkthrough - you have to consider and cover every eventuality and this often results in further refinement of the design. Usually I find at the end of the process that enough has been learned that if I were designing and writing the code again there are things I could do better. And some of those things are perhaps too 'baked in' to the structure of the code to warrant spending the time to make the changes.

It often seems to me that in an ideal world I would always plan to go through the above process with the intention of using it as a learning process, and to plan to rewrite. Noting that much of the nuts and bolts of the code (e.g. low level subroutines) will be re-usable, so it's not a full bottom up re-write.

redcalx
  • 345
  • 3
  • 14
  • 2
    **[Unclear what help you need](http://meta.programmers.stackexchange.com/questions/6559/why-is-research-important "see: 'Why is research important?'")**. Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it’s hard to tell what problem you are trying to solve or what aspect of your approach needs to be corrected or explained. See the [ask] page for help clarifying this question. – gnat Feb 24 '15 at 17:51
  • 1
    possible duplicate of [Refactor or Concentrate on Completing App](http://programmers.stackexchange.com/questions/23021/refactor-or-concentrate-on-completing-app) –  Feb 24 '15 at 18:02
  • 1
    Plan to Throw One Away (The Mythical Man Month) – imel96 Feb 25 '15 at 00:29

2 Answers2

2

Everything you say in your question is absolutely true, though I have a feeling that many companies don't actually go through quite the same thought process as you.

Your thought process is (more or less, for any significant piece of code) "I need a day to write it, a day to debug it, and a day to refactor it." Your company is saying "You need a day to write it."

Your company knows that time to market is everything; a marginal piece of software that strikes gold first often wins market share over the highly-polished latecomer. It's even worse than that; the first to market isn't always the one that strikes gold; often, a company has to go through many iterations of a product before people like it and embrace it. King wrote almost a hundred games before Candy Crush came out, and Candy Crush represents something like 75% of their revenue.

Consequently, companies will almost always push to get the product out the door at the expense of clarity and elegance of code. It's not the most comfortable position to be in as a software developer, but it is a challenge met by those who can balance the need to meet deadlines with the need to reduce technical debt as much as possible.

Also, remember that customer feedback is paramount. Unreleased software doesn't get customer feedback and it doesn't make any money. The sooner that a product gets released (consistent with stability and a reasonable feature set), the sooner you can find out what the customer really wants. This is the big reason that agile methodologies that get early customer feedback are now favored over "big design up front" methodologies like waterfall.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 1
    I recently read a book explaining that waterfall was never really used in practice and it always served mostly as an illustrative example. So the dichotomy between the agile present and the waterfall past is artificial. The amount of upfront design that is needed is guided by factors like the cost of failure. The fact that methodologies with less upfront design have become popular is due to the fact that there are much more low-risk projects (e.g. web applications) compared to more traditional software like banking applications, air-traffic control software, and so on. – Giorgio Feb 24 '15 at 19:02
  • 2
    @Giorgio - I've been saying that since I've been on Stack Exchange. Early customer feedback = GUI Prototype/Mockup. To create good requirements you need to do some Preliminary Design and iterate between the 2 phases. Same goes for every phase. You iterate between the phase before and after. Iterative builds (ie build 1 build 2 build 3) are standard waterfall practices. The main difference is that in waterfall, you aren't done until you deliver what the customer asked for and you know what you are building ahead of time. In agile, you are done when the money runs out, wherever that leaves you. – Dunk Feb 24 '15 at 22:58
0

You are describing a core component of clean coding.

No matter how well you think you design something up front, development is an iterative process that demands change. You start with the high level overview of a system and design accordingly. Maybe you go through several ideas before settling on the right idea.

Then you start diving into slightly more detail. Maybe you see that your original design needs to be changed. Maybe it needs to be replaced entirely. This is a natural consequence of a top-down approach to design that is so common in our industry.

If you develop using an iterative approach (who uses Waterfall anymore?), the details necessarily move from coarse (early sprints) to detailed (later sprints) as you code more and more functionality. This may involve changing earlier code to work better with requirements implemented in later iterations.

This is natural and good: embrace the change.