[HN Gopher] Software Development: Mistakes I Made
___________________________________________________________________
Software Development: Mistakes I Made
Author : herodotus
Score : 46 points
Date : 2020-04-25 14:46 UTC (8 hours ago)
(HTM) web link (billwadge.wordpress.com)
(TXT) w3m dump (billwadge.wordpress.com)
| kccqzy wrote:
| > However this time I didn't rush to implement, thanks mainly to
| the influence of Ed Ashcroft. In retrospect Ed's first impulse
| when he had an idea was to document, not implement. We produced a
| series of widely read papers and soon had other researchers and
| brilliant students of our own working on it.
|
| I'm not sure this actually applies to most people. The document
| vs implement struggle is something I see in modern software shops
| a lot. It certainly depends on the personality: some people just
| like thinking through everything and producing a coherent writeup
| before writing a single line of code, but for some writing code
| itself is an act that clarifies the still-murky concepts and
| helps to produce a good writeup.
|
| But in the end, most people aren't producing novel enough
| technologies that the benefit of a complete writeup is there. You
| don't write something brilliant and have other researchers work
| on it; you merely write something for the benefit of a future
| colleague understand your code quickly. It's a very different
| class of software development.
| ansq wrote:
| > "for some writing code itself is an act that clarifies the
| still-murky concepts and helps to produce a good writeup."
|
| This is my philosophy after ~2 years of working on distributed
| systems. I got sick of vague design discussions where everyone
| has a 5 minute memory.
|
| I am much happier to sit at my desk and figure it out by
| writing code, then produce a design doc once I have a solid
| prototype working. It feels more honest and real.
|
| At the same time, I wonder if I'm missing out on a different
| way of doing things.
| cheez wrote:
| As long as when you're writing code, you're solving only
| immediate problems in a lightweight way, this is the way to
| go.
|
| Most people, of course, overengineer. I remember being on a
| project where a guy wrote 5000 lines of code to put two
| columns in a specific browser.
| to11mtm wrote:
| For me, it depends on the problem being solved.
|
| If the problem is in a space that we know what the solution
| 'should' look like, getting as much of that down in the most
| abstract sense is something I like to do. However that design
| is only a -proposed- solution, and of course subject to all
| sorts of changes.
|
| But where things are murky in a design, yeah, sometimes the
| easiest thing to do is code it out.
|
| In either case, (up to date) diagrams of data flows are one's
| friend in any distributed system.
| jasonpeacock wrote:
| Most modern software shops don't document at all. They would
| definitely benefit from writing down a problem statement and
| description of the solution so that everyone is on the same
| page.
|
| Documenting doesn't have to mean design-first development, it's
| a way to make sure you're working the right problems and
| building the desired solutions before you waste your time
| writing code.
| mgkimsal wrote:
| I've tried to force myself to write something in English
| before coding, and... it's not 100% followed, but it's often
| helped. Sometimes I'm not even prescribing the full
| 'solution', but it's a sketch of the pros/cons of a couple
| approaches. This can help me remind myself later of why a
| particular option was chosen, even if it turns out to be bad.
|
| I can't say if anyone else who looks at the code ever also
| reads what I've written - it seems that generally they don't
| (even though I announce it and it's in the commit activity
| stream and PRs).
| akkartik wrote:
| Lovely stories hamstrung by the perceived need for a moral.
___________________________________________________________________
(page generated 2020-04-25 23:00 UTC)