Live data from Hacker News

Things I've learned about writing software after 12 years

medium.com

31–40 of 122 posts

Re: Things I've learned about writing software after 12 years

#31

There's a sentiment in the article I see a lot that keeps coming up these days: "NASA sent a spaceship to the moon with something 100x slower than my computer, so why does it take so long to load a page"? I think it's entirely unjustified. What makes modern software engineering difficult is that it's one of the few engineering disciplines where not only are you making a Boeing 747 fly, and all the parts were made by…

> The moon landing really was nothing compared to this.

I used to believe that, but I have slowly moved to the other side.

Things are complicated. There is no doubt about that. But, landing on the moon was a fight against nature (gravity, air, distance, etc). Current programming is a fight against stuff someone else dreamed up and no one ever fixed, because "LOL, that's old school" or "You're just doin' it wrong".

Most of the points about parts not being specified correctly, not working as expected, or disappearing happens all the time in other industries. (That's one reason hardware kickstarters fail so often.)

Re: Things I've learned about writing software after 12 years

#32
post #29
post #19

Earlier quoted context omitted.

"We get the software we deserve." Painfully true. There are techniques for writing better software. They work. They take longer and cost more. They are not widely used outside aerospace.

Is there a high level overview somewhere I can read? Don't even know what to google here.

http://spinroot.com/gerard/pdf/P10.pdf (some are more/less appropriate for non-embedded-systems)

In general, the answer typically involves formal specification and formal methods that check the code against these specifications, combined with testing and coding standards that result in analysable code.

More references:

https://www.cs.umd.edu/~mvz/cmsc630/clarke96formal.pdf

http://research.microsoft.com/en-us/um/people/lamport/tla/fo...

Re: Things I've learned about writing software after 12 years

#33
post #11
post #6

Earlier quoted context omitted.

Or writing at higher level than a 12 or 13 year old :-)

Beyond the grammatical errors, misplaced punctuation and misspellings, and despite the relative novelty of the anecdotes, I thought the writing itself was dull and simplistic. Many paragraphs were just a string of blunt statements without any independent clauses. According to a copy+paste of the text into http://sarahktyler.com/code/sample.php , the article as a whole reaches Flesch-Kindaid grade level 7.

So, it was written such that a 7th grader could read it. How is that a bad thing?

Edit: I pasted a sample of John D MacDonald in there and it showed a level of 6.61. Poor John, no wonder he was never a success. /S

Re: Things I've learned about writing software after 12 years

#34
post #18

The ideas behind this article are good. The author gives some guidelines that have helped them write better software. However, it makes me think about how we can make "making software" better. It seems like the best current way of going about it is to implement these zen-like self-discipline techniques that have helped the OP. What's so inherently wrong about software? Why is it so damn difficult to write software th…

"Why is it so damn difficult to write software that doesn't explode if you don't hold your tongue at the right angle?"

Hubris mostly.

Re: Things I've learned about writing software after 12 years

#36
post #29
post #19

Earlier quoted context omitted.

"We get the software we deserve." Painfully true. There are techniques for writing better software. They work. They take longer and cost more. They are not widely used outside aerospace.

Is there a high level overview somewhere I can read? Don't even know what to google here.

You might want to look into coding standards for C and special languages like Ada (like C, but less writeable, more readable with strong types) and Esterel (deterministic multithread scheduling). Seriously, Esterel is probably the coolest thing you'll read about this week.

There's also various specification languages for multithreaded behaviour, which allows you to analyse your programs behaviour using software tools, for example SPIN[0].

0: http://en.wikipedia.org/wiki/SPIN_model_checker

Re: Things I've learned about writing software after 12 years

#37
post #5

Not sure what all the hate is about. He presented some interesting anecdotes about the quirks of software engineering and then tied it all together with some concrete lessons. Maybe 5K words without any sort of lists or clickbait titles is just too much for the average reader.

You figured it out. People didn't like the article because they're too stupid to read that many words. Or they were confused by the title.

It's not cause the tone is accusatory, or because it rambles, or compares mission critical life-or-death Apollo software with the unimportant web and native applications we write now. Yep, it's cause people are too dumb to look at that many words without a beer commercial dropped in the middle of it.

Saying "people who disagree with my opinions are too stupid to understand the subtlety of the point" is the rhetorical equivalent of denial in the Kubler-Ross sense of the word.

Re: Things I've learned about writing software after 12 years

#38
Wow. It feels like I wrote that article I agree with it so much. There are a few things I disagree with:

1. I'm not a TDD purist but I do think a red/green TDD cycle does strongly encourage all of the following things to happen in a more natural, flowing way: "Tell yourself what you’re going to do, and then implement that sentence. When you’re finished, take that sentence and write a test, then just move on." Coding before testing isn't the issue as much as the potential for needing to change code just to be more testable (an efficiency issue).

2. No sale on the idea of documenting every piece of code; I truly feel like doc comments muddy the contents of the file, plus resulting documentation is less likely to be read than code and more likely to fall out of sync with the contents of the code. Completely separate documentation is hard to keep updated. It's often something to maintain with often no tangible benefits unless you are churning developers like crazy. Certainly it might be reasonable to document high-level interactions for complete view of the system but documentation at lower levels seems an increasingly bad value proposition to me. In a perfect world, sure... but in real life there are deadlines and tests+code almost always serve as enough of a developer guide to understand clearly. If not, I'd rather spend time refactoring instead of writing docs. For the few new developers brought on, reviewing the system in a paired programming manner is a good way to get to know them and ramp them up at the same time. Parts of the system that are difficult for them to comprehend might warrant refactoring attention.

3. "If something is performed more than three times in a 4 hour span" It's difficult to make a wholesale suggestion on things like that. If said task is 1 second clicking the "get mail" button and automation is auto-checking every n minutes, automation can be a net loss in terms of productivity. I think the XKCD[1] chart is probably a better measure ;) Anyhow it's definitely better to not waste loads of time doing things you do often, and the more often you do something the more likely it is that automating the task would pay off; just don't do it with an utter lack of discretion.

Some typos in the post: - Stray period before "I just call it by what it was: A big ball of mud." - "Simple isn't sexy." should maybe be "Complex isn't sexy" or "Simple is sexy" - "internet" (proper noun) - "explaining just how the interact with" s/the/they - "english" (proper noun)

Very thought-provoking and fun read (lots of laughs)- I really look forward to future posts!

1. http://xkcd.com/1205/

Re: Things I've learned about writing software after 12 years

#39
Sean Parent would bring up the fact that given enough scale all systems end up being a network problem. If you look at the internet, you can think of it as one big system. Huge and hideously complex, its pieces are connected but not dependent.

If you can boil your software down to parts that can afford latency (even if they need throughput), you can pass messages between them. That is possibly and probably less efficient, but your macro pieces that pass well defined messages between each other can exist without adding to the complexity of the other pieces.

Re: Things I've learned about writing software after 12 years

#40

There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…

which is why a software project requires someone with technical knowledge doing the management, and not an MBA or "project manager" who cares only about on budget and on time at the cost of technical quality.
Post reply on HN