Characteristics of Software Technical Expert - As documented by Hemant Shah

Hemant Shah listed these characteristics of a Software Technical Expert in a mail to participants of Accelerated Technical Expert Program. I think this is a great list and forwarded this mail to various other Teams in Geometric Ltd. I am reproducing the list here as it will be great reference to everyone.

(PS - Hemant has uncanny ability to simplify complex ideas to simple core concepts. If you are in GeometricPLM/HCL Technologies, don't miss his sessions) 

 

While Nitin has been articulating the qualities which he wants to see in Techincal Experts,
Here is a list of things which has been compiled.

I understand that it might sound too much of super-human-like. Also most of the things you would already know.

This is just to document things in a single place.

Note that not all of them are unique or mutually exclusive. Some of them might be repetition of already mentioned points, with a different view point.

Technical Expert

1. A Technical Expert should be able to design a software.
2. A Technical Expert should be able to implement a software.
3. A Technical Expert should have a wide-ranging experience.
4. A Technical Expert should be the go-to person in the team for Technical queries.
5. A Technical Expert should be able to give Technical Presentations.
6.  A Technical Expert should be able to make, review, evaluate a Technical Proposal.
7. A Technical Expert should be able to formulate Technical Guidelines for e.g., Technical Coding Guidelines etc.
8. A Technical Expert should be able to evaluate a new software and give recommendations.
9. A Technical Expert should do Technical Bench-marking.
10. A Technical Expert should be aware of / read technical standards.
11. A Technical Expert should be aware of / read latest things available in his/her field. 
12. A Technical Expert should be member of Technical bodies. 
13. A Technical Expert should write Technical Blogs.
14. A Technical Expert should be able to compare and evaluate two software.
15. A Technical Expert loves challenging problems and attempts at solving them.
16. A Technical Expert should answer queries which are posted on Technical Forums.
17. A Technical Expert should take part in Technical Competitions. 
18. A Technical Expert should be a judge of a Technical Competition. 
19. A Technical Expert should attend Technical Conferences / Events. 
20. A Technical Expert should be a Speaker at Technical Conferences / Events. 
21. A Technical Expert should be able to guide / mentor new comers in the organization and the project team.
22. A Technical Expert should be able to analyse technical reports / findings.
23. A Technical Expert should have some preliminary business sense. 
24. A Technical Expert should be aware of the various tools available in his/her field of expertise, or should be able to find out and figure out.
25. A Technical Expert should take part in Techathons, Hackathons. 
26. A Technical Expert should have in-depth knowledge of a particular topic / subject. He / she should be an authority on that subject. A Technical Expert should have broad knowledge of other areas. 
27. A Technical Expert should have broad knowledge of the various Software Development Processes
28.  A Technical Expert should be part of the Technical Evaluation / Promotion of Individuals. 
29. A Technical Expert should improve the efficiency of the Team on Technical
30. A Technical Expert should share his/her knowledge across multiple domains.
31. A Technical Expert should share technical information with others.
32. A Technical Expert should inspire others also to become a Technical Expert.
33. A Technical Expert should do external Technical Certifications. 
34. A Technical Expert should be an innovator. 
35. A Technical Expert actively contributes on Social Media. 
36. A Technical Expert knows how to build a technical team. 
37. A Technical Expert challenges his / her peers with technical problems.
38.  A Technical Expert comes up with other challenging problems. 
39. A Technical Expert should be a curious person. He / she should be an early adopter of a new technology. 
40. A Technical Expert comes out with challenging test papers / question papers for the next generation to solve.
41. A Technical Expert should be able to talk to, articulate things to non-Technical folks like Human Resources, Business, Finance, Sales, etc.
42. A Technical Expert should be able to simplify complex topics so that other non-technical folks or other technical folks are able to understand and comprehend the complex topics.
43.  A Technical Expert should be able to take Technical Interviews. 
44. A Technical Expert should be able to sustain a dialog with other Technical Experts. 
45. A Technical Expert should be able to teach others about the Technical Skills which he/she has acquired.
46. 48.  A Technical Expert should be sincere, perseverance, able to express, diplomatic, great inter-personal skills, approachable. 
47. A Technical Expert should be an avid reader.
48. A Technical Expert is a Guru.
49. A Technical Expert is a Final Authority on Technical matters. 
50. A Technical Expert is a Role Model for others.

Insights from ‘The Design of Design’ - Part I

I have good fortunate of meeting/interacting with some great software designers while working in Geometric Ltd and during last two years as independent consultant. I am always intrigued by how an expert software designer thinks and how he learns. As Sir Ken Robinson says the key skill in today's world is ‘knowing how to learn new things’. I think of myself as ‘Thinking Craftsman’ (i.e. someone who is thinking about his trade/craft and strives to continuously improve his/her skills). Hence ‘how an expert designer learns and becomes an expert’ is a key question for me in the quest of improving my own skills.

‘The Design of Design’ is a new book from Fred Brooks (Author of Mythical Manmonth). As expected, it has some great/some obvious insights but most importantly it has great explanations of these insights. In this article, I am going to discuss about insights related to how ‘expert designers become experts’.

Insight One: Exemplars in Design
This is what Fred Books says about 'exemplars'

Exemplars provide safe models for new designs, implicit checklists of design tasks, warnings of potential mistakes and launching pads for radical new designs. Hence great designers have invested great efforts in studying their precedents. Bach took a six month unpaid leave to study the work and ideas of Buxtehude. Bach proved to be much greater composer but his surpassing excellence came from comprehending and using the techniques of his predecessors and not ignoring them

I argue that great technical designers need to do likewise but that the hurried pace of modern design has discouraged this practice. ... Technical design disciplines eager to produce great designs need to develop accessible bodies of exemplars and knowledgeable critiques of them (page 154-155)

‘Certainly lazy or slack designer can minimize his work by picking an exemplar and just modifying it to fit. By and large, those who just copy do not draw on ancient or remote exemplars but only on those that are most recent and fashionable’ (page 162).

There are two things that came to my mind after reading this article. First is ‘Design Patterns’. “In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.”.

One purpose of documenting the ‘design patterns in software’ is to 'make experts insights available to a novice’. In this sense, ‘Design patterns’ fit perfectly into what Fred Brooks calls ‘accessible bodies of exemplars’. Personally my thinking about the software design changed after I studied patterns (especially advantages and limitations of each pattern). Even today I read and reread GoF Design pattern book, articles by Robert Martin, articles and books of Martin Fowler, books like Effective C++ and More Effective C++. Every time I gain some small new insights which enrich my own ‘body of knowledge’. Another recent good book of exemplars is ‘Beautiful Code: Leading Programmers Explain How They Think’. There are positive and negative reviews on this book. For me, this book is invaluable for its insights into how various developers think about a problem and how they come up with a solution.

Second thought was ‘about Googling’. Recently (past few years) I see many developers just google about a problem, find something and copy that code. Many times they just pick up some pattern and copy the sample code for that pattern found on the internet. But since they don’t have any real understanding of the pattern, they end with more problems. While conducting programs on ‘design patterns’ I see participants eager to get sample code rather than eager to understand the pattern, participants eager to get the ‘power point slides’ rather than reading the books and articles. So far I have not found any solution to this ‘lazy or slack designer syndrome’. Bigger problem is many of these lazy/slack designers are considered ‘good/great designers’ in their company because they can rattle of latest technology and design buzz words.

For many years I regularly read blogs, various book and studied how other good designers think out of habit.But I could not clearly explain/articulate a new comer why I am doing this. Now I know how this habit has helped me and how it can help a new comer to study his craft.

The Design of Design : New book from Fred Brooks

Some time back I blogged about the 'Mythical Man month'. Recently I have started reading the new book from Fred Brooks.' The Design of Design'. Like Mythical Manmonth this book is also a collection of essays and it also a book where you read a chapter and then you need to think and reflect on the ideas/thoughts in the chapter and your own experiences before continuing to next one.

First thing that struck me about this book is Authors gives examples from diverse fields  like music, civil engineer and construction apart from Software. These examples illustrate the author's knowledge about these other fields. I am greatly impressed by the case study about design of auhor's house and kind of design notes that he kept through out the process. I wish I was this systematic.

The book is divided in 6 sections

1. Models of Designing
   So models of design talks about the 'engineer's view of design, about Water fall model and why it doesn't work and what are possibly better design models.
   
   In my 15 years of experience, I have never seen 'water fall model' work in practice. However, all the software development processes defined in software companies implicitly assume 'water fall model'. End result is developers hate 'these processes' and organization cannot get expected benefits of process implementation. Someone (I think Albert Einstein) once said that 'Insanity is doing the same thing, over and over again, but expecting different results'. By this definition, many common software development 'processes' in software companies are 'insane'.
2. Collaboration and Tele collaboration
   Now a days any significant sized project is about 'collaborating with other' for design, coding/construction, testing etc. In the world of 'outsourced software development', tele-collaboration is increasing critical. As expected, Fred provides some insights on what works and what doesn't.
3. Design Perspectives
   Talks about various 'views' about the design, user models, aesthetics, constraints, examplars (or design patterns), where things go wrong.
4. Dream system for design houses.Authors thoughts and ideas for a 'dream system' to design houses and why of those ideas
   
5. Great Designers.
   Talks a common argument that software development should be like a 'factory'. Good Product development process will produce 'good designs'. I have heard this argument many times from Software Engineering Process Groups (SEPG) in the companies, CMM and ISO style processes etc.While, Fred argues that 'Great Designs come from Great Designers'. He also goes into the depth of why we need Product processes and how to make product processes that encourage and facilitate great design. I think this is a chapters that every manager should read.
6. Case studies.

It is not possible to reviews the ideas in this book in one article. So I am hoping to write multiple articles as I assimilate ideas from this book.

Rereading Mythical Manmonth - Flowcharts and UML

This is a second entry about Rereading Mythical Manmonth. You can read the first one here.

When I started programming, I never used to create 'detailed flow charts' while many people (usually who are not actively coding) urged it. I did create some small flowchart to get overall picture in my mind but never detailed flowcharts. Later same thing happened with UML diagrams, I always felt little guilty about it. Till I read, Fred Brooks observations about Flow charts.

These are the Fred Brooks observations about Flow Charts in section named 'Flow Chart Curse' (in essay 15, The Other Face).  

The flow chart is a most thoroughly oversold piece of program documentation. Many programs don't need flow charts at all; few programs need more than a one-page flow chart. 
....
The detailed blow-by-blow flow chart, however, is an obsolete nuisance, suitable only for initiating beginners into algorithmic thinking.
....
In fact, flow charting is more preached than practiced. I have never seen an experienced programmer who routinely made detailed flow charts before beginning to write programs. Where organization standards require flow charts, these are almost invariably done after the fact. Many shops proudly use machine programs to generate this "indispensable design tool" from the completed code. I think this universal experience is not an embarrassing and deplorable departure from good practice, to be acknowledged only with a nervous laugh. Instead it is the application of good judgment, and it teaches us something about the utility of flow charts.

Try replacing the 'Flow chart' in the above discussion with 'UML Diagrams' and the whole discussion now suddenly seems very recent discussion. In my experience 'UML Diagrams' are more preached that practiced and most of the time these diagrams are created 'automatically' from the code at the end of development cycle.

Obviously with UML also, I create a few class diagrams and sequence diagrams to clear top level picture. But I don't create very detailed UML diagrams of every single class and function. In my experience, when a team tries to create very granular UML diagrams :

• it confuses every one in the team, 
• it takes too much efforts 
• and hence not really worth it.

However, many times Customers and internal SEPG groups ask for UML diagrams (sometimes because of mostly misguided notion that a UML documented design means 'good design', sometimes because of everybody is doing it, sometimes because of all the UML hype).

Still I could never clearly explain why UML is not a 'silver bullet' in documenting software design. That is till I reread the 'No Silver Bullet' and the section 'Essential difficulties->Invisibility'.

Software is invisible and unvisualizable. Geometric abstractions are powerful tools. The floor plan of a building helps both architect and client evaluate spaces, traffic flows, views. Contradictions become obvious, omissions can be caught. Scale drawings of mechanical parts and stick-figure models of molecules, although abstractions, serve the same purpose. A geometric reality is captured in a geometric abstraction.

The reality of software is not inherently embedded in space. Hence it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics. As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs, superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These are usually not even planar, much less hierarchical. Indeed, one of the ways of establishing conceptual control over such structure is to enforce link cutting until one or more of the graphs becomes hierarchical.

In spite of progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, thus depriving the mind of some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it severely hinders communication among minds.

Since software is inherently 'unvisualizable' (as explained above), software developer will always feel that any graphical modeling technique (Flow charts, UML Diagrams, Swimlanes, data flow diagrams, etc etc) is insufficient to imagine and communicate the software design.  

So in conclusion:

• Software design is hard.
• Documenting and communicating software design is even harder.
• Flowcharts, UML diagrams or any other diagrams are not a silver bullet of 'design documentation'.
• Most likely, there will never be a 'silver bullet' in design documentation.

UPDATE (Oct 30, 2010):

I fully agree that UML diagrams are useful communication tool to document/discuss/understand the overall design. However, it utterly fails as  'documentation' tool for documenting every class and function. Documenting every single class with UML results in information overload. So I agree with observations of 

Stephan.Schmidt and others.

In one of the project that I worked, we had about 10 different modules. Each module had some 2/3 key classes. We created module dependency diagram. We documented the class hierarchy (inheritance and aggregation relationships) of these classes in a single class diagram. We also documented names of various design patterns used in these classes. Then we documented key functions of these modules with 2/3 sequence diagrams. This documentation served us well. New team members can quickly get the hang of the system and start contributing.  

 

At the end of the project, our customer insisted on UML diagrams for every single class and function. Hence we reverse engineered whole system and created UML documentation of every single class. It was completely incomprehensible and hence completely useless.

Rereading Mythical Man month

Recently I started rereading Mythical Man Month by Fred Brooks. The book is a collection of essays about programming and software development in general. First edition was published in 1974. I am reading the 20th Anniversary edition published in 1994. So the one I am reading is also 16 years old.

First time I read this book sometime in year 2000. At that time, I was a just a somewhat experienced developer. In last 10 years, I have handled teams, worked in project leader roles, taught software development, design, architecture.  Now when I started rereading the book, its a very interesting and educational experience. Some things which I did not completely understand or believe at that time, now those ideas make sense. Though the ideas and advice in the book are still very sound advice even after 35 years. Still this book  is known as a book 'that is quoted often but followed rarely'. I agree to that.

I am going to review some ideas on the book which stuck a cord.

I found a following gem in Chapter 13, The Whole and The Part. Here Author is talking about the 'System Debugging'. 

Build Plenty of Scaffolding

By scaffolding I mean all programs and data built for debugging purposes but never intended to be in the final product. It is not unreasonable for there to be half as much code in scaffolding as there is in product.

One form of scaffolding is the dummy component, which consists only of interfaces and perhaps some faked data or some small test cases. For example, a system may include a sort program which isn't finished yet. Its neighbors can be tested by using a dummy program that merely reads and tests the format of input data, and spews out a set of well-formatted meaningless but ordered data.

Another form is the miniature file. A very common form of system bug is misunderstanding of formats for tape and disk files. So it is worthwhile to build some little files that have only a few typical records, but all the descriptions, pointers, etc.

I suddenly realized that the description is very similar to description in Agile books/articles about Test Driven Development. (with some minor change in terminology). 'dummy component' is Mock Objects. The estimate of proportion of 'test code' to 'production code' is also very similar('It is not unreasonable for there to be half as much code in scaffolding as there is in product' )

I found few more such gems. Later I will write about them.

Notion of Repeatable processes

From the recent discussion on PragmaticProgrammer Mailing List:

(From Mail from Andrew Hunt)

Here's a side question for ya'll on the notion of repeatable process: I want a formula of how to make a hit movie. Perfectly repeatable, with no consideration of the talent involved. Just turn the crank and rely on the process to work.

Now replace the 'hit movie' with Software Product/Project. I never seen the concept explained with such a simple and thought provocating metaphor.

The Quotes I liked - Software Development

1. Computer science is not the same as Software Engineering.

2. "First make it work, then make it right." OR "Make it work, Make it right, Make it fast"- Kent Beck (I think)

3. "In my experience, the customer doesn't know what he wants until you don't give it to" --David Brady on the XP Mailing List


Update - I have created presentation from More such quotes collected over years and its now on slidshare 

The Quotes that I liked - General

These are some of my favourites quotes. Usually I use one of them as signature on my mails.

1. To attain KNOWLEDGE, Add things every day;
To attain WISDOM, Remove things every day.
-- Lao-Tse

2. "You ordered a first-rate article and you must be content to pay the price"

-- Joseph Clement (engineer, corresponding with his client, Mr. Charles Babbage)

3. "The definition of insanity is doing exactly what you did before all over again, but expecting different results this time."

4. Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning. --Albert Einstein

Update - I have created presentation from More such quotes collected over years and its now on slidshare