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.

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.

Review: Scalability Rules

This is the review I posted to Amazon on the book Scalability Rules:

Get this book if you're transitioning to the services world or want to improve your skillset without having to make all the mistakes yourself.

The proposal of this book is to present the topics briefly. Once you read these rules, take them to your heart and, from there, learn how to apply it specifically in your environment. It will probably involve doing a lot more reading and experimenting, but at least this book will give you the starting points.

If you have some experience developing and operating a world class service, then you will quickly notice that the authors do know what they're talking about. I've had this experience as a service developer and operator and can definitely relate to most of these lessons.

Also these lessons do not apply only to web sites, but to any web services; and it's beyond scalability, it's about the mind shift to the services world. Developers that did not work on services tend to think they are relatively similar to product - and they are NOT. Companies transitioning from a product to a services focus should buy several copies of this book and give one to each developer, because you can get most of these rules if they are taken into account from day one, not as an afterthought.

.NET - Reactive Extensions (Rx) for event-based programming

One of the nice .NET features I learned recently is called Reactive Extensions. This is a very nice library that allows asynchronous and event-based programs to be used as collections. I found it particularly compelling to learn it as I see more and more code being written in async way and event-driven. However, if you're not so used to this kind of programming, it is hard to wrap your mind around code that makes use of it - and debug and find where issues can be when they arise.

Reactive Extensions moves from a pull-model to a push-model, where instead of having a collection that implements an IEnumerable, you have an IObservable that you subscribe to. Your delegate is then called whenever an event is dispatched by your source. But it's not only that. You can make use of many Linq operators to make your code much simpler.

I'd recommend that you watch the videos on the following page:
http://msdn.microsoft.com/en-us/data/gg577611

Out of these videos, do the workshops and try the challenges. Since they are not ordered on the page above, let me list them in order here:
http://channel9.msdn.com/Series/Rx-Workshop/Rx-Workshop-Introduction
http://channel9.msdn.com/Series/Rx-Workshop/Rx-Workshop-Observables-versus-Events
http://channel9.msdn.com/Series/Rx-Workshop/Rx-Workshop-Unified-Programming-Model
http://channel9.msdn.com/Series/Rx-Workshop/Rx-Workshop-Writing-Queries
http://channel9.msdn.com/Series/Rx-Workshop/Rx-Workshop-Schedulers
http://channel9.msdn.com/Series/Rx-Workshop/Rx-Workshop-Event-Processing

Finally, another good link is this page with tens of Rx samples:
http://rxwiki.wikidot.com/101samples

Posts on new C# 5.0 features

I came across a couple of good posts on new C# 5.0 features that are worth reading:

Asynchronous Programming in C# 5
What else is new in C# 5?

I like in particular the async programming support being added in this new version of the language.

Windows Azure Dev Fabric: access it remotely

One of the common topics on Windows Azure is how to access remotely a compute emulator, or the development fabric (dev fabric). This is not, of course, a solution for production, but it can come in handy when you're developing two systems on separate computer and you need to test their integration before deploying them to Windows Azure.

The problem with the development fabric is that it binds to the looback device only, so it works only if accessed by the localhost address (127.0.0.1).

The computer emulator shows that it bound to 127.0.0.1:

Also netstat output shows it:

So a remote access, which would hit the local interface, would never access your locally running application. In order to to do that, there are multiple options. Windows offers a command-line utility called netsh.exe that helps rerouting port accesses and would be great to use, but it doesn't work for loopback interfaces, so unfortunately it can't be used in this case.

Another good option is to tunnel the request via SSH. I tried that by installing Cygwin + OpenSSH, and it worked beautifully. I add some references to it at the end of this post if you're interested in this option.

However, the easiest way to get this accomplished was by using an application called "PassPort port forwarding utility Win XP", which is hosted on SourceForge.net:

http://sourceforge.net/projects/pjs-passport/

By configuring it to forward from my local interface IP address to 127.0.0.1, I can access the application remotely. For instance, if your external IP is 192.168.0.1, this would be your configuration:

Just click on "Start" to start PassPort as a Windows Service and you're done. No need to change anything on the remote side other than pointing it to your IP:Port.

Another alternative, that I did not try myself, is rinetd. It is mentioned in the post below and if you have any experience with it, please post a comment:

http://blog.ehuna.org/2009/10/an_easier_way_to_access_the_wi.html

References for OpenSSH

http://pigtail.net/LRP/printsrv/vista-cygwin.txt

http://pigtail.net/LRP/printsrv/passwd-group.html

http://www.acooke.org/cute/CygwinSSHS0.html

http://www.kgx.net.nz/2010/03/cygwin-sshd-and-windows-7/comment-page-1/#comments

http://blog.ehuna.org/2009/10/accessing_the_windows_azure_lo.html

Software Liability

Interesting article on how software creators should be liable for its consequences:

Today the operant legal concept is "product liability," and the fundamental formula is "if you make money selling something, you'd better do it properly, or you will be held responsible for the trouble it causes." 

Some say the only two products not covered by product liability today are religion and software. For software that has to end; otherwise, we will never get a handle on the security madness unfolding before our eyes almost daily in increasingly dramatic headlines.  

http://queue.acm.org/detail.cfm?id=2030258

Review: The Art of Readable Code

This is the review I posted to Amazon on the book The Art of Readable Code:

In short: this book deserves a space on bookshelf and not only for yourself, but to serve as reference when reviewing other's code. And not only reference: this is a short book that you can done in a week or two, like the authors say. I read it cover to cover and finished it within 10 days.

It is straight to the point, has a lot of funny and relevant cartoons, and packs great pieces of advice on how to write readable code. Many of these lessons seem to be common sense, but when I started paying attention to code other engineers developed, I saw how much the lessons taught in this book were not being applied. And I am talking about senior engineers here as well. I even took my own code, which had been checked in a few days earlier, and improved based on these tips.

I believe that many of these tips one can get from reading code written by good developers. I got many of them early in my career from reading the Linux kernel, for instance. But until you put these tips in practice and start seeing your code using these lenses of readability, you will be probably missing out on many of them.

In terms of contents, the authors start with names (incredibly important), but they go all the way to refactoring the code by extracting unrelated subproblems. One are that I liked in particular is how to make your comments useful, describing precisely and in a compact way.

Finally, for those who tend to disregard these tips in favor of "getting things done" and don't care about readability, the authors present an example of a supposedly simple minute/hour counter and show how valuable an organized and readable solution is.

Visual Studio extension: ReSharper

I've been working with ReSharper for a week or so and definitely recommend it if you're developing in Visual Studio. It is amazing how more productive you become once you start using its features.

One of the videos I watched to become familiarized with ReSharper is this:

http://tv.jetbrains.net/videocontent/resharper-tips-and-tricks-live-session-at-ndc-2011

It does talk about many of the tips and tricks, including a very good tooling around HTML and MVC.

I'd say that it may be worth the investment for a personal license. I guess I am getting spoiled and it will be hard to go back to other IDEs.