
The design and implementation of software systems - kiyanwang
http://zsck.co/2016/03/31/the-design-and-implementation-of-software-systems/
======
extrapickles
One important part is once you have broken the project up into tasks, is to
simplify (eg: these two tasks could be different views of a core feature) once
you have all of the tasks in hand. If you try simplifying before you have a
mostly complete idea of the scope, you end up with useless abstractions and
other overly complicated code (eg: the ObjectServiceFactoryConfiguratorEngine
that only loads a simple json config file during app startup that took months
to write).

Also, I've found it handy to have a line or two of the issue this is trying to
solve for the user in the user story. To go with the user story example in the
article, it should also have: "User frequently schedules appointments from the
animals they have viewed recently". That way when implementing the feature one
can tell if they are over complicating things when the user actually wants
something to make their job easier/simpler or can help uncover hidden
requirements that were undiscovered in previous steps (eg: the buttons should
be blindingly obvious or more hidden).

------
sna1l
> Talk to stakeholders and try to gather as much information about features
> and requirements as you can.

This. I think so many times when new software is being designed, this step is
glossed over. So often have I seen engineers barge ahead with their design,
send it out for review, and receive comments that would have been addressed
with the slightest bit of research and communication.

------
agentultra
Diagrams are next to useless in my experience. They tell you nothing about the
execution of the system, it's properties, invariants, etc.

If diagrams were all we needed to design software we'd all be writing UML
right now and proving our systems correct with it.

A better alternative is to look into specification languages and the awesome
tooling around them. Unit-B, TLA+, etc.

------
jimjimjim
Diagrams can be great. but i feel like there are two completely separate ways
of using them. The first is from the overly formal world of software
engineering (e.g UML diagrams) where they were meant to act as a formal
specification for others to follow. Luckily this practice is a lot less
common.

The second way is to use diagrams as a digital 'back-of-beer-coaster' tool to
help you break down the big picture into smaller chunks. They also help you
see at a glance areas that need more attention and also if more info from
other people/systems is required.

and generally, screw the logic. What's the data? and where does it go?

~~~
AnimalMuppet
Pro tip: Don't use the back of a beer coaster, use a napkin. They have more
space.

------
eternalban
The title is too grandiose. I clicked on this expecting a comprehensive book
backed by serious experience.

