Habits of Expert Software Designers • Hacker News Board

Re: Habits of Expert Software Designers

#131

Post by andrewstuart » Wed, Oct 09, 2019, 3:34 AM UTC

I'm not going to claim "expert", but I have designed more software than I can even remember.

Some of my approach:

-- I strive primarily to form a clear and simple mental model of the system that the software will represent.

-- Simplicity is everything in software design and should be priority one. Conversely, you must actively avoid complexity, and when part of a system is starting to feel complex, take a step back and rethink the approach. Sometimes systems must include complexity, try to contain this all into a tightly constrained area of the system.

-- Loose coupling of system components is next most important - priority two - when designing large interconnected systems - you'll succeed in designing something big if you can instead make a number of smaller systems that know as little as possible(ideally nothing) about the other parts of the system.

-- Software is like painting - you can't plan every brush stroke in advance - instead you get the broad brush strokes in place and then paint ever finer levels of detail.

-- I strive for consistency, but not slavishly. Try to use the same approaches/technologies everywhere if possible. When not possible, choose the most suitable technology/approach and use that.

-- I'm extremely hesitant to allow special cases or exceptions, but I will happily do so when it is clearly necessary.

-- I grant myself time to think about possible solutions even when there is pressure (typically from myself) to be actually implementing/coding a solution.

-- I do my best to "design out" or get rid of software - the fastest, easiest to write and most reliable code is no code.

-- I try to lean heavily on the capabilities of existing systems like database and web servers. If you really understand what existing systems are capable of at a deep level then often you can avoid reinventing the wheel and hook in to what those existing systems do.

-- I'm not a fan of complex systems such as containers and kubernetes. I have been able to build all my software architectures without them.

-- The project build should primarily aim to put together a working ended to end system that does the absolute minimum to enable the integrated whole to work - i.e. you need to build just enough of each thing to put a pig in one end and get sausages out of the other..... without much attention to anything like user interface or error handling or really much of anything else at all. This is because it is much easier to complete a system that is working, even if only minimally.

-- I'm happy to throw away previous decisions and system components if they have proven to be wrong.

About 1,000 other things I don't have time to think out right now.

Re: Habits of Expert Software Designers

#132

Post by andrewstuart » Wed, Oct 09, 2019, 3:40 AM UTC

WalterBright wrote: post #127

These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine.…

>>I look at everything I've written 5 or more years ago, and it's all garbage.

From Walter Bright? Sorry I don't buy this. I can accept that you might feel it could be better, but garbage? No.

Re: Habits of Expert Software Designers

#133

Post by inopinatus » Wed, Oct 09, 2019, 3:45 AM UTC

agumonkey wrote: post #129

inopinatus wrote: post #128

Earlier quoted context omitted.

"Feynman was a truly great teacher. He prided himself on being able to devise ways to explain even the most profound ideas to beginning students. Once, I said to him, 'Dick, explain to me, so that I can understand it, why spin one-half particles obey Fermi-Dirac statistics.' Sizing up his audience perfectly, Feynman said, 'I'll prepare a freshman lecture on it.' But he came back a few days later to say, 'I couldn't d…

> That means we don't really understand it. I wonder if other physicists shared the sentiment.

I hope so. I've always thought the quintessence of science is pushing back the boundaries of ignorance. To advance we must first understand the true outline of our incomprehension. In that light, I don't think Feynman's remark is a negative sentiment at all.

To know what what you do not know, etc. (c.f. confucious 2:17, rumsfeld 2:02)

Re: Habits of Expert Software Designers

#134

Post by nine_k » Wed, Oct 09, 2019, 4:15 AM UTC

Izkata wrote: post #126

nine_k wrote: post #99

Earlier quoted context omitted.

One problem is that Java lacked functions until Java 8. It still sort of lacks them internally, but tat least you can write free-standing functions here and there, and especially as lambdas inline. Another problem is that Java lacks type aliases. If your data have a complicated type like List >>, you have to copy-paste this type everywhere, without a way to name it succinctly. On top of that, Java lacks type inferenc…

> If your data have a complicated type like List >>, you have to copy-paste this type everywhere, without a way to name it succinctly. Java has had generic type inference since at least 7 [0], so all you need is It's not perfect, but I believe it's been improved with each version. [0] https://docs.oracle.com/javase/7/docs/technotes/guides/langu...

Yes, this is what I called "diamond operator".

I'm talking about a different use case where inference via assignment does not work, e.g. a method declaration:

    public List>> combine(
      List>> a,
      List>> b
    ) {...}

It would be great to have something like

    type Quux = List>>;

    public Quux combine(Quux a, Quux b) {...}

Unfortunately, I'm not aware of any plans to introduce that.

Re: Habits of Expert Software Designers

#135

Post by KajMagnus » Wed, Oct 09, 2019, 5:34 AM UTC

WalterBright wrote: post #127

These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine.…

> "deliberately seek elegant abstractions"

This advice is too abstract, to be practically useful in real life. ? Is it a bit like saying: To be a good runner, do this: Run fast. — Needs to be broken down into smaller more actionable steps.

Still the other advice about talking with users, and looking around at other things out there, and spending time "thinking into the future" about how one's ideas will work out, and what to not include in the software — I like that advice :- )

Re: Habits of Expert Software Designers

#136

Post by hinkley » Wed, Oct 09, 2019, 7:03 AM UTC

erikpukinskis wrote: post #130

WalterBright wrote: post #127

These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine.…

> > they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." > Every developer I've ever talked to believed down to their core that this was what they were doing. Really? I’ve worked with a lot of people who are just trying to make the thing do the thing. Even most of the people who are interested in good abstractions often are under suc…

Not all developers are doing this, no. But pretty much all the ones I’d like to strangle are.

It’s elegant! No, your dumpster fire of a Second System Syndrome is not elegant. Fractal designs are not elegant. Also you are in your late 30’s. Why are you just having your second system syndrome now?

Re: Habits of Expert Software Designers

#137

Post by hinkley » Wed, Oct 09, 2019, 7:05 AM UTC

andrewstuart wrote: post #132

WalterBright wrote: post #127

These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine.…

>>I look at everything I've written 5 or more years ago, and it's all garbage. From Walter Bright? Sorry I don't buy this. I can accept that you might feel it could be better, but garbage? No.

No, I know exactly what he means. I sometimes get irritated with code I wrote a year or so ago, and that feeling is compounded the farther back you go. And that’s not counting the spots where I catch myself doing things I’ve told others to avoid doing.

Re: Habits of Expert Software Designers

#138

Post by WalterBright » Wed, Oct 09, 2019, 7:26 AM UTC

andrewstuart wrote: post #132

WalterBright wrote: post #127

These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine.…

>>I look at everything I've written 5 or more years ago, and it's all garbage. From Walter Bright? Sorry I don't buy this. I can accept that you might feel it could be better, but garbage? No.

Here's a piece I was proud of 20 years ago. Can you count all the ways it's a steaming pile?

https://github.com/dlang/dmd/blob/master/src/dmd/root/outbuf...

I've recently fixed a number of its problems, but it's got a ways to go. Am working on it this evening.

It needs to be better because earlier today I found a bug enabled by its poor design:

https://github.com/dlang/dmd/pull/10462

Re: Habits of Expert Software Designers

#139

Post by WalterBright » Wed, Oct 09, 2019, 7:28 AM UTC

hinkley wrote: post #137

andrewstuart wrote: post #132

Earlier quoted context omitted.

>>I look at everything I've written 5 or more years ago, and it's all garbage. From Walter Bright? Sorry I don't buy this. I can accept that you might feel it could be better, but garbage? No.

No, I know exactly what he means. I sometimes get irritated with code I wrote a year or so ago, and that feeling is compounded the farther back you go. And that’s not counting the spots where I catch myself doing things I’ve told others to avoid doing.

> I catch myself doing things I’ve told others to avoid doing.

Now and then I'll publish some guidelines for writing better code, and someone always points out that I violate them myself and contradict earlier dicta :-)

Re: Habits of Expert Software Designers

#140

Post by UweSchmidt » Wed, Oct 09, 2019, 7:59 AM UTC

andrewstuart wrote: post #132

WalterBright wrote: post #127

These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine.…

>>I look at everything I've written 5 or more years ago, and it's all garbage. From Walter Bright? Sorry I don't buy this. I can accept that you might feel it could be better, but garbage? No.

Programming is finding abstractions, and those change as a program, and the understanding of the problem grows. Abstractions then have to change again as the program interacts with other systems, and to accomodate typical patterns of changes in the requirements which can't be predicted beforehand. Abstractions then have to change again to facilitate understanding the entire thing, and to accomodate technical changes, or allow easier bug finding.

I'd say, a real-world program that's beautiful 5 years later is ...something special :)