INCOSE Systems Engineering Handbook short review.

systems-engieers-handbook-book-cover

(This is an old post that I have forgotten to re-post here. Original date: 30 June 2018)

In two words: unless you work in a company of more than 10000 people, you don’t need it.

In more words:
Some time ago I became increasingly suspicious of books and films without authors. For some reason, ‘collectively’ or ‘in the name of an organization’ written books tend to be not as useful as those which have some author’s name on the front page.

And this book was a relatively nice example. Well, it has ‘some’ authors mentioned in a fineprint piece of technical text on the second page, and by a sheer coincidence the book turned out to be better than completely authorless books tend to be on average.

Nevertheless, the book completely lacks the general picture of the field. The beginning, which is expected to give a broad overview, before plunging into the details in the latter chapters, is in fact full of citations of ‘revered people’s work’, but short of actual definitions or explanations of what’s going on.

The rest of the book is filled with ‘process descriptions’, which are presented in a relatively obscure marketingese, which, if purified, happen to be job descriptions templates. Pretty useful for bosses willing to write instructions for their subjects, but not as useful for people who actually understand what their employees should do. (That is, they rule less than 1000 people.)

The last part even suggests to semi-automate the process of writing instructions to people using the ‘sysml’ diagram notations (which, is not properly supported anywhere, since all CASE development systems were designed with octopi in mind), which is so cumbersome that to be justified unless your company has less than 1000 people.

The book is pockmarked with references to how useful NASA, JPL and various other well-known guys find the suggested model, but let’s be honest, what the reference _actually_ tells is is that if you are smaller than NASA, don’t even think about adopting such a huge bureaucratic model of an organization.

Conclusion: unless you REALLY know what you’re doing, stay away from UML, SysML or huge bureaucratic organizations which care more about insuring you against legal consequences than actually doing something new and technologically breaking through.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s