Sunday, May 20, 2012

Review: Influencer

This is the review I posted to Amazon on the book "Influencer: The Power to Change Anything":

This book condenses great tips on how to influence something - or as the subtitle says: "the power to change anything". It gives starting points on how to influence, and the main sources of influence, which are:
- Make the Undesirable Desirable (Personal Motivation)
- Surpass Your Limits (Personal Ability)
- Harness Peer Pressure (Social Motivation)
- Find Strength in Numbers (Social Ability)
- Design Rewards and Demand Accountability (Structural Motivation)
- Change the Environment (Structural Ability)

All sources of influences are full of good examples of influence masters weaving into the text to explain the concepts. While I enjoyed these examples, I believe the authors could have made the book shorter, still conveying the same message. That is pretty much the reason I did not give this book 5 starts.

On the content, some of the pieces of advice seem quite obvious. Either I had realized some of the influence techniques mentioned in the book and had started putting them into practice or I asked myself "why hadn't I thought about this before?". Others pieces of advice are definitely more subtle and amazed me when I read them.

The main lesson from the book is that there are many more techniques that can be used to influence than one probably learns just by observation. On top of that, probably not a single technique will be enough to promote change. Out of one's toolbox, some of the techniques must be picked according to the influence project and audience in order to accomplish the goal of changing something. Picking the "proper" set of influence techniques is a skill that one can learn with practice.

In order to be really effective in promoting influence, one could try to learn all techniques by himself. Another options is try to learn the techniques used by influence master and that's what this book does, it provides that knowledge and can save you substantial time in your process of being more influential.

What the book mentions, but do not stress enough, is that this is a process that takes time and patience. This is not a book to provide a quick way to change yourself or people around you. It's a very sensible book that, based on experience and research, teaches you down-to-earth techniques that can help you promote the change you want. Note that it won't be fast or easy, but like every other skill, it's about setting your mind to it and practicing.

Saturday, May 19, 2012

Code coverage and missed requirements

Sometime ago I wrote a post about how high code coverage may not necessarily mean something.

This time I want to expand on that and talk about missing requirements. It's clear that high code coverage doesn't mean that your code is well tested, but oftentimes the main argument to use it is that it will detect gaps that must be tested. The implicit assumption in that is that we have all the requirements captured and in the code. What if this is not true?

As Robert Glass says, "it is difficult to test for something that simply isn't there. Some testing approaches, such as coverage analysis, help us test all segments of a program to see if they function properly. But if a segment is not there, its absence cannot be detected by coverage approaches."

Also, a good point that Glass makes is that, even other approaches like code reviews, "may or may not so readily spot pieces of code that are totally missing."

That is why it doesn't matter the methodology, if requirements are missed, logic will be missed in the resulting software. And it's more likely than not that these will be missed until it gets to production. Once it hits production, this omission will have the highest code to be fixed (as compared to early in the development).

Software design: simplistic or optimal?

"It is hard for other people to give up on the notion of design simplicity. For example, the notion of simple design is espoused in some of the new methodologies, such as Extreme Programming (XP) and Agile Development (AD) (they suggest seeking the simplest design solution that could possibly work). Certainly, for some kinds of very simple problems the design probably can be made simple. But for problems of substance, the XP/AD approaches harbor serious dangers." - Robert Glass, "Facts and Fallacies of Software Engineering"
This quote hits home. Recently I've worked on a high-level design for a problem and, while a challenging problem from technical, I noticed how much people think differently about designs. Not only from this recent experience, but from other experiences, I can see the designers leaning towards XP/AD approaches, where one just take the requirements at hand and solve the problem. The main point is that you can't anticipate the future and things change, from business priorities to technologies, so it's very likely that you will scrap that design and do something different anyway. With that in mind, why overengineer the solution?
"Missing requirements are the hardest requirements errors to correct." - Robert Glass, "Facts and Fallacies of Software Engineering"
This other quote also hits home. In the rush to get some designs done - who can wait for the requirements to be clarified? - there's a tendency to go with a solution that satisfies the known requirements. By not going the extra mile and trying to find out the direction the company is going into and taking that into account, you take the risk of moving on with a solution that cannot be reused with the requirements that could have been uncovered and taken into consideration. One important point, though, is that there are various levels of design decisions that one can be made. Whether you go with data store A or B can have a significant impact and be very hard to change later without a major rebuild of the software. Making a wrong low-level design, while also having some cost to redo and improve, can be much more isolated and manageable.
"[...] that leaves us with the notion of optimal design. There are a few people who believe in seeking and achieving optimal design, particularly those who espouse scientific approaches to the problems of business applications (for example, so-called management scientists). But all too often those optimality-seeking scientific approaches work only for a vastly simplified version of the real problem being undertaken. In those circumstances, a solution may, in fact, be optimal but at the same time be useless." - Robert Glass, "Facts and Fallacies of Software Engineering"
The other extreme takes place when an "optimal" solution is attempted. Better to quote Glass again, "For complex processes, we learned from Simon (1981) that optimal design is usually not possible, and we must strive instead for what Simon calls a 'satisficing' solution. Satisficing (rather than optimizing) solutions are those that can be seen to satisfy enough of the criteria for a good design that it is worth taking the risk of choosing that approach and proceeding with problem solution, given that an optimal design is likely to be either impossible or not cost-effective to find." I've seen that happening as well, and either the designer never gets anywhere, or it's cut short in the interest of time and design turns out to be worse than if a more pragmatic solution had been attempted.

Ideally we'd like to take a pragmatic approach from the hardest design problems and try to clarify requirements along the way. Definition of "hardest" and critical requirements is a judgment call are among the things that will depend quite a lot on the designer's experience. Also the experience will help decide what is to be left aside or deprioritized, as well not designed at all at a high-level - and left to the coder to work on this design.

Overdesigning a solution where the coder doesn't make any decision and does not exercise creativity is another point that must be avoided. The line where one may be missing important design aspects and where one is overdesigning is blurry, and top designers tend to know where it lies.