Writing Software: Refining/Optimizing Style (Options)
| TLDR: (1) Work first version then refine (2) Refine as you go alongsame as writing draft or storytelling – to write a first draft and then revise, or – to revise as we go / edit as we go learned keyword: |
When writing software, is it better to write a working version first and then refine, or to refine as you go along?
From: https://www.quora.com/When-writing-software-is-it-better-to-write-a-working-version-first-and-then-refine-or-to-refine-as-you-go-along
writing software options
– write a working version first and then refine, or
– to refine as you go along
which one is better?
– for typical web development : incremental delivery
– for other domains：incremental delivery can be problematic
this is possible in most domains:
– create and test in small units
– create prototypes, etc.
incremental delivery is often not feasible in these domains:
– client-facing
– system-integrated functional software in many enterprise and industrial settings
– heavily regulated applications
consider incremental delivery for:
– a proton beam controller for medical treatments
– aeronautical/astronomic applications where cost/risk of failure is extremely high
–> failures will still happen
–> but the goal is
to minimize them and weigh against cost/time/risk factors
Conclusion:
– Software is a very wide field
– Different domains and projects dictate different needs for tools and methodologies.
– Understand what's needed then choose wisely.
– Don't assume there's a "one size fits all" approach.
– The old saying of "there are no silver bullets" stills holds true (and likely will for the forseeable future).
Necessity:
for clients to understand the need for
– testing,
– security,
– maintenance, and
– other aspects of development
The former: write a working version first and then refine
The trick is:
to learn to deliver frequent new working versions as you add features (and fix bugs)
Incremental development:
– beginning stage:
> running product soon
> then can confirm (or revise) your architecture/design
– later stages
> keeps you from wasting too much effort on speculative development that doesn't pan out
> keeps you focused on periodically delivering updated working software.
– Most software is never "finished" until it is retired
– incremental development:
> in sync with this reality (i.e. most software is never 'finished')
> tends to produce better results
> less wasted effort and stress
– Refining as you go is disaterous
> You'll end up in a cycle of refinining what you already refined
> You'll lose sight of the requirements quickly.
WRITING OPTIONS, which one is better
– to write a first draft and then revise, or
– to revise as we go
The first one: to write a first draft and then revise
Analogies: When we iron a shirt,
– to iron heavily in one portion and
– then expand that well-ironed bit further
> careful to not run out of steam before finishing the whole job
> careful of this result:
— one area of your work will be perfect but other parts have been barely touched
— this principle can be applied to storytelling
— your draft will suffer and the uneven nature will take ages to fix
Do not edit as you go
Do not let yourself run out of steam
Don’t look back
Don’t look at the text output.
> Any misspellings will only make you want to stop and press backspace.
Only forward!
The only way to write a good movie is to write a bad movie first and then revise.
Interesting:
What is the best approach for improving code: refactoring or rewriting?
This decision depends on scale – how much code must be re-written or refactored?
In his book Clean Code, Robert “Uncle Bob” Martin relayed an inside story told to him about a company that had developed a “killer app” (think Lotus 1-2-3 or Netscape Navigator). Seeing maintenance and development costs increase, management recruited an “A-team” of developers who started a complete rewrite that promised to be “more betterer”. After two years, version 2 was complete, but then required all the new features added to version 1 during those two years. …
https://www.quora.com/What-is-the-best-approach-for-improving-code-refactoring-or-rewriting
Interesting:
Which one is better to optimize a software for better performance
– at the beginning or
– at the end of the development?
– premature optimization is the root of all evil
– you cannot see into the future
– you cannot predict what problems you will encounter
– If you try to fix a problem that isn’t there, you are going to make a huge, irreconcilable mess
> (a) waste your time
> (b) make your code convoluted
> (c) miss the real problem, or
> (d) all of the above.
The correct time to start optimization:
– when you measure that some performance criteria has become a bottleneck, or
– when there is an imminent danger of becoming one
– need to have a workload model
– need to do stress tests as soon as possible
The right thing to do at the beginning of the development
– to make sure your architecture can scale
This will give you more options as you hit bottlenecks down the road.
Interesting topics:
What is more important, writing good code or writing fast code? Why?
Both writing good code and writing fast code are important, but the emphasis often depends on the context. Here's a breakdown of each:
1. Good Code (Readability and Maintainability)
Code should be easy to understand for other developers (or even your future self).
Readability:
– promotes collaboration
– simplifies debugging
– simplifies extending the code in the future
Maintainability:
Good code is often structured in a way that allows for easy updates and modifications.
– Bugs are easier to fix, and new features can be added with minimal disruption.Scalabil
…
https://www.quora.com/When-is-it-better-to-optimize-a-software-for-better-performance-at-the-beginning-or-at-the-end-of-the-development
writing a piece of code
– implementing a workable solution, and then improve it later with better algorithms or code, or
– try to ascertain the best algorithm first before coding
– refinement after writing your code
– think-time ahead of writing it
– tweaking and fiddling once something’s working
When having no idea how to do something:
– if I spend too much time thinking about it
> I never get started
> I fall into analysis paralysis
– It’s better to cobble together something that works (even if poorly),
> to experiment and understand the problem space better
When to do software optimization:
– central dichotomy
– performance is potentially highly dependent on detail
– a very small coding change can make a big difference to performance. …
Writing piece of code:
– First, make it work correctly, and prove that it works correctly. This includes thread safety if that's part of your environment.
– Second, make it robust in the face of unusual or invalid inputs. Make sure what ”robustness” means in your situation . Understand your caller’s capabilities.
– If any resources need to be optimized ( speed, memory, db connections, whatever), find the acceptable limit in the deployment environment, and work to meet that limit. Depending on your employer, you may not need to prove this, but you should have convincing measurements.
– Simplify. Meeting all of your goals with code that can be easily understood by college student is better than exceeding your requirements with code that is more complicated.
– Document.
> the requirements
> the business reason for those requirements
> the failure modes
— Give a synopsis if intended operation
— Leave references to tests and results.