Some background. Skip it if you want to get to the summary/breakdown of the actual text.

I recently went through my very first bit of system design interviewing. It was a 45 minute mock interview where I was building the infrastructure for a small e-commerce business. I went well over an hour, had to stop multiple times to break character and ask questions of my interviewer, and only got as far as finishing the frontend and doing a little bit of data modelling (which was seriously flawed).

I was both daunted and thrilled by the process. It was a type of thinking that I was not familiar with, and scoped much larger than anything I'd built before. Having to architect an end-to-end solution was a unique challenge, and one that I wasn't quite up to. I'm excited to dig into system design a bit deeper, so I picked up Structured Analysis and System Specification by Tom Demarco. While I expect that it will be a higher-level perspective than what I had to do, I'm hoping that it'll provide some high-level insights into system design and the types of concerns that are at play when I'm trying to structure a project.
This series will consist of me reading a chapter of the book and writing a summary/reflection of each. This is chapter 1.

1: The Meaning of Structured Analysis

DeMarco starts with the idea of Structured Analysis. Structured Analysis and Structured Specification provide us with a conceptual overview of a system. It's a design document that leans heavily on charts and visualizations, which are built to quickly communicate the structure of the system we hope to build. This approach has the downside of requiring a lot of overhead before we're able to start actually creating anything, but has the benefit of necessitating a clear understanding of both the problem we aim to solve, and the strategies we use to accomplish this.

There are a few parts to the planning process. We have to select a goal, decide on metrics, make predictions regarding important parameters of the task (price? timeline? workforce?), and build a consensus from all of the involved parties.
I'm not going to go too in depth with these, but there are a few points that I felt were notable:

• Estimates are important, but are often created without any basis in reality (and no one is good at making them)
• Analysts are primarily tasked with preventing failure (rather than ensuring success)
• Failures often happen because we've had problems with our analysis that weren't apparent until far too late interpersonal politics are a deeply important factor in a project's success and should not be downplayed
• The domain shifts, and our plans must shift with them. (and our plans should be maintainable / adaptable enough to do so)

DeMarco proposes that Structured Analysis should produce a document called the Structured Specification, which will make use of data flow diagrams, a data dictionary, structured English, decision tables, and decision trees.
I'm assuming that these will be explained in more detail further down the line. Again, it seems to lean on the immediate legibility of charts, and the much higher bandwidth of information that can be conveyed through them (as opposed to pure text documents - ironic that I'm blogging about it, huh?)

Overall, this type of analysis seems to be an exercise in mediation. You're placed in the task of massaging disparate tasks together, easing transitions from one phase of the project to the next, managing competing needs and desires, and providing safeguards against potential points of failure.

I'm particularly fascinated by the consideration given to interpersonal relationships (described as politics), since it feels like a very un-engineer way to approach analysis/design. That type of concern is out of the scope of my own project of systems design, but it'd be extremely helpful to understand once I'm working with teams at scale.

(DeMarco also namedrops Merce Cunningham as an inspiration, which made the artist in me nerd out a bit.)

One of the big problems I had in terms of working with a team wasn't any sort of lack of engineering skill, but rather, a lack of effective project management. We didn't have a clear direction, which made it difficult for any of us to build towards an end project, or take initiative with respect to our goals. It honestly felt worse to be aimless than it did to be working at 11pm during a crunch, and I'm hoping to do a bit of a postmortem at some point.

Next time, we'll get started on chapter 2, Conduct of the Analysis Phase.