| 12 More Essential Skills for Software Architects |
|
Author: David Hendricksen
First, a warning. If, like many i-programmer people, you’re a fan of code and logic, someone who likes nothing better than actually writing programs, this book is really not for you. It’s designed (as the title suggests) for software architects. The back jacket does claim that it covers technical skills, but we’re not discussing being able to write a fast fourier transform without mangling your butterflies, or the ability to decode a non-working recursion without gibbering. Instead, this is the type of book that has sections on ‘ideation’ and on ‘strategic roadmapping’. At one point it devotes half a page to a stick drawing titled ‘learn to understand what the customer values’, where smiling stick-person 1 is handing a 0 in a box to smiling stick-person 2. This may well make you want to throw the book down in disgust. On the other hand, if you read what the author is actually saying, he turns out to be talking reasonable sense for the most part. It’s just not technical skills as we know it, Jim. This is a follow-on book to David Hendricksen’s 12 Essential Skills for Software Architects. The first time round, Hendricksen covered ‘soft skills’ - relationship, personal, and business skills and Sue Gee, I Programmer's training, education and careers specialist, awarded it a rating of 4.5. This time out, he’s turned his attention to technical skills. Hendricksen is an architect for Thomson Reuters, who works on big data projects, and the advice he gives in both this and his previous title is based on how to work in a large company where you have to fit in with the wishes and wants of executive users.
The book is divided into three parts, covering project skills, technology skills, and visionary skills. Part I looks at project skills – how to create partnerships with the people on your project, how to discover exactly what the customer really wants, how to conceptualize the client’s ideas into something that can be implemented. The most technical chapters in this section are on estimation, where Hendricksen comes up with some good questions to pose when calculating how much a project might cost, and on management. As with other areas of the book, the advice might seem obvious, but it does make sense – don’t say no, give options; don’t spring surprises on executives, keep them in the loop.
Part II covers technology skills. There are chapters on platform development, architectural perspective, governance , and know-how. The chapter on architectural perspective has some nice definitions of various architectural principles – the principle of least surprise, least knowledge, least effort, opportunity cost, single responsibility, parsimony and last responsible moment. The chapter on know-how is also good, especially the list of questions to ask about new technologies. If a few more people asked things such as ‘where are people struggling when they implement it’, it would avoid a lot of jumping on bandwagons only to have to jump off again a year down the line. The last part of the book looks at visionary skills. A chapter on technology innovation discusses how you can develop relevant trend awareness and apply it to your business. Strategic roadmapping is the next topic, laying out milestones that lead to achieving a particular vision. The book closes with a chapter on entrepreneurial execution, ways of finding new and innovative ways to solve problems. Overall, I felt Hendricksen talked a lot of sense and had some interesting insights in this book. Time and again I’d get to a topic that sounded like management hype, but read on and find myself agreeing with what the author was saying. If you want to become a software architect (or improve your architecture skills), this is a useful read, hence the rating of 4. If you are a proud programmer, that rating of 2.5 carries a warning - leave it on the shelf for the sake of your blood pressure.
<ASIN:0321717295> |
|||
| Last Updated ( Saturday, 28 November 2020 ) |
