Righting Software: A Method for System and Project Design • By Juval Löwy • Addison-Wesley Professional • 444 pages • ISBN: 9780136524007 • $49.99 / £37.99
In a world where low-code and no-code tools mean that pretty much anyone can build an app, most software is still inherently buggy. Much of it is rewritten repeatedly and hard to maintain, even though software development is always in motion. Death marches may have been exchanged for agile stories and continuous delivery, but deadlines and estimates for software still seem hard to pin down.
As software of one sort or another now powers everything from cars to medical equipment to utility infrastructure to high-frequency stock trading, surely we can become better at building it?
The root cause of all this expensive, buggy, complex software that's delivered late, hard to maintain and doesn't do what it really needs to do? "Poor design, be it of the software system itself or the project used to build that system," says Juval Löwy in Righting Software: A Method for System and Project Design. Naturally, he has an alternative.
But don't be put off by the pages of fulsome praise for the author's classes that this book opens with (even before you get to the colophon or table of contents), which make what the author calls 'The Method' sound rather like a miracle diet or the latest herbal superfood. The rather brutal evaluation of the state of most software development in the preface is a much better introduction to a book that's not about coding, or even development, but structured, systems-based software engineering.
If the pun in the title sounds familiar, it dates back to a Microsoft Research paper about the static analysis tools in use at Microsoft in the early 2000s: Löwy's approach is on a completely different level, and it's about design.
The role of design generally in business -- as opposed to industrial design, typography or user interface creation -- has been getting a lot of attention in recent years, with everyone from Uber and Atlassian to IBM and McKinsey hiring designers en masse (or acquiring design firms) to bring 'design thinking' to more products.
At the highest level, The Method is straightforward: design the system in a few days, using a decision tree to make sure later design decisions don't derail things, and don't design to the requirements but deliver the smallest set of components that can deliver a distillation of the core use cases; then validate the design thoroughly, communicate clearly not only what the design is, but why it was chosen, and manage the project just as thoroughly.
Opinionated
Digging into the detail reveals that Löwy is very opinionated about some software design practices, from avoiding both functional and domain decomposition to service naming conventions. The first half of the book covers the software design principles, including a fairly novel idea he calls 'volatility' -- finding what's most likely to change and encapsulating that component so you can change it with the least impact on the rest of the software architecture. Be prepared for a certain amount of repetition; the author likes to introduce ideas and then circle back to build on them in a later chapter.
The 'real world' examples of all the worst ways to build a house are perhaps rather overdone (analogue metaphors for the digital realm aren't particularly useful), but they convey the idea that absurd amounts of reworking are routinely done in software development without getting bogged down in arguments about specific languages and frameworks. Much more useful is the sample system architecture based on an actual software development project the author's consultancy IDesign was involved with -- especially the way it covers communications and business alignment as part of the project, because software development isn't done in a vacuum.
In fact, the whole second half of the book delves into details of project design that are normally left to formal project managers: staffing plans, budgeting and estimating, critical path analysis, earned value planning and other techniques for understanding resource and time planning and cost management. None of these are new ideas in technology. As Löwy points out, they go back to DuPont production lines and what General Electric learned designing the GE-225, arguably the first commercial transistor-based computer. But they will be novel to many developers and software architects.
Given the increasing understanding that software development is a team sport, it's disappointing that there's nothing on diversity or the human side of project management here. Non-technical managers are dismissed as not understanding how hard software design is, while the team of developers is treated as faceless resources; all we get is advice to assign interactive components to developers who work well together (which raises other issues about hiring for culture fit rather than skills).
Another question is how well you will understand something like risk after reading a single chapter on it. Also, the project design analysis of the sample system architecture is oddly split into one rather abstract and less relatable section and then a later, more detailed walk-through. The Method expects software architects to acquire skills that would often be certifications in another field, but again the wider questions of professionalising software engineering aren't really explored. Some of this material may well be more useful as part of one of the classes IDesign runs, or as an introduction to further research by the reader (it's a shame there isn't a suggested reading list for this in the book).
Self-referential
The footnotes contain too many references to both Wikipedia and Löwy's other writing, while the captions are cluttered by credits to stock image services for some reason. Also, Löwy's habit of coining his own terms for concepts like giving managers multiple options to choose from, and combining estimates from a wide group of people, means that you're suddenly reading about optionality and broadband with completely different meanings from their actual definition.
Many of the references are classics -- Parkinson's Law, Dunning-Kruger, Fred Brooks (of The Mythical Man-Month), David Parnas inventing modular software design in 1972. In fact, apart from a reference to Brexit as an example of unexpected change that the sample software architecture had to cope with, and a thorough demolition of microservices as prone to excessive granularity (a point made by many proponents of microservices), there's little here that couldn't have been written 20 years ago. Löwy touches on actor patterns (as used in Project Orleans) as an emerging trend, but there's no mention of DevOps, CI/CD pipelines, A/B testing, distributed systems or agile methodology. These are not necessarily incompatible with The Method -- they're just not the level of software architecture Löwy is talking about.
SEE: Top IT certifications to increase your salary (free PDF)
This isn't simply formalised waterfall development though, despite the emphasis on initial design: it includes project management advice on dealing with the unexpected, although the assumption seems to be that most of this will come from management.
Righting Software isn't just a book for those who have attended the classes that produced the encomiums that fill its opening pages. That said, either those classes or training on the project design techniques will probably give anyone adopting the structured and rigorous approach it documents a higher chance of success. The Method is very much aimed at systems engineering: it's not the only possible solution, but if your organisation doesn't have a successful system for software design and development, these 'tried and true' methods may dig you out of a hole -- even if you don't agree with all of the strong opinions.
RECENT AND RELATED CONTENT
Microservices: The foundation of tomorrow's enterprise applications
What do software developers want? A chance to learn, and a decent corporate culture
Programming languages: Developers reveal what they love and loathe, and what pays best
Project Reunion: Microsoft's unified app strategy is still missing one piece
Microsoft: Here's why we love programming language Rust and kicked off Project Verona
Read more book reviews
"book" - Google News
June 03, 2020 at 02:56PM
https://ift.tt/3gN27Us
Righting Software, book review: Building blocks for software architects - ZDNet
"book" - Google News
https://ift.tt/2Yv0xQn
https://ift.tt/2zJxCxA
Bagikan Berita Ini
0 Response to "Righting Software, book review: Building blocks for software architects - ZDNet"
Post a Comment