
Software Development: Mistakes I Made - herodotus
https://billwadge.wordpress.com/2020/04/25/the-secret-of-software-success/
======
kccqzy
> 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
> "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.

~~~
macromagnon
This reminds me of TDD arguments.

If I'm working within a system I like to code the minimum golden path, add a
tests that passes, then add more checks or a new test and go back to the code,
etc. Usually the constraints of the system point the way to an obvious
skeletal implementation and you can learn as you go along.

On a greenfield project it is especially valuable to have discussions
beforehand if people have done something similar before but talking about code
at a high level tends to become nebulous rather quickly.

~~~
war1025
I think the philosophy behind TDD is really valuable in the sense of "start
with a goal in mind", but I find that I get better results with running and
iterating than going to the effort of writing tests all the way out.

Probably just a mismatch of our testing tools vs the types of things I need to
develop usually

------
frequentnapper
I had the bad fortune of taking this guy's "computer science" class a long
time ago as an undergrad. He spent the entire first week covering WW2 and
other history. Then during the rest of the semester didn't teach anything.

The icing on the cake was when we were handed evaluation forms he said to the
class "It doesn't matter what you fill out because I have tenure."

~~~
bade
What I meant was, say what you think, don't worry about getting me in trouble.

As for the course , you''re saying I didn't teach for the future. Guilty.

~~~
frequentnapper
You didn't teach anything. Period. This was the opinion of all my classmates
and others I knew who took your class. If you don't believe me, see for
yourself:
[https://www.ratemyprofessors.com/ShowRatings.jsp?tid=48636](https://www.ratemyprofessors.com/ShowRatings.jsp?tid=48636)

~~~
bade
I clearly remember teaching the resolution proof method, adversarial graph
search (games), the state of automatic language translation, Bayesian spam
filtering ... maybe you weren't paying attention.

~~~
frequentnapper
I got an easy A in your course. How would that happen if I weren't paying
attention?

~~~
mesaframe
So, he taught topics.

~~~
frequentnapper
Not really. I don't remember learning anything and I still got an A just like
most of the other students. Teaching is more than just providing a syllabus
and then lazing around in the classroom.

~~~
gen_greyface
>I got an easy A in your course. How would that happen if I weren't paying
attention?

This statement implies that something was taught, what else can help you get
an A with your attention

~~~
frequentnapper
Yes you caught me lying. "Something" was taught. How clever of you. /s

------
dacox
Hey, Bill Wadge was a prof of mine! It was a topics in Artificial Intelligence
course just before the Deep Learning boom. It was all about entailment and
modal logics and frankly seemed really out of date. It was interesting,
however.

------
wmichelin
This seems to directly contradict YAGNI. I find that when I "write for the
future", I over-engineer things and they get messy and bloated.

~~~
breischl
I took his meaning as "assume better hardware will be available in the
future", which is not what you seem to mean, and may not be as true these days
anyway.

That said, when I've seen people over-engineer things (and maybe this isn't
your problem, it's just what I've seen most) it's usually because instead of
solving the problem in front of them, they created a flexible framework to
solve a class of problems including the one in front of them. And it usually
fails because they don't actually _know_ what other problems they'll encounter
- they guess and get it wrong. So their framework is flexible on Dimension X,
but they actually need it to be flexible on Dimension Y.

The best advice I read on this was to never build a framework until you have
at least 3 examples of the problem. Once you've got 3 examples, you have a
good feel for which ways it needs to be flexible. I would add that you should
also make sure you'll eventually have more than 3, because if 3 is the total
number of concrete examples you still don't need a framework.

Also, it's entirely possible some smart guy/gal can give you those 3 examples
before you even start building. A good product person can do that. If you have
that, _and_ they're pretty sure you'll actually get there, then go ahead and
build it.

Difficulty of changing it in the future also plays into this, but I've typed
too much already. :)

------
dullroar
Back in the 1990s, when I was a software engineer at a database company in the
Bay Area (rhymed with "PsyBass", if you pronounce "bass" as a musical
instrument :), there was a joke among some of the architects along the lines
of, "I __DREW __the boxes and arrows! If you can 't implement it, that's
you're fault!" Now, as a "software architect" in a really, __really __small
shop, I basically just try and lead by example, and make sure my ideas work as
code before inflicting them on anyone else. But that sorta sounds like keeping
it all to myself until I am sure it works, per the article. I like to document
(more than most), but have found over the years the only person who reads my
documentation tends to be me. So writing docs or writing code, either way,
tends to help me refine my ideas.

------
philipwhiuk
Write for the future sounds great until you remember hindsight is 20-20 and
predictions aren't.

~~~
clarry
Yep. You can write for a future where desktops boast single-core speeds in the
10GHz range. That's how you get Crysis, which still has performance issues on
the latest CPUs.

------
akkartik
Lovely stories hamstrung by the perceived need for a moral.

------
some_eejit
I was a CS student at Warwick (UK university) in the late 80s, and clearly
remembering doing functional programming with Lucid. Never heard of it since.

------
coldcode
Everyone makes mistakes, the key is to find ways to avoid making them over and
over.

