sfeldman.NET

After reading “Implementing Lean Software Development: From Concept to Cash”, I decided to look at the original book. It is as good as the successor. IMO reading the original one first even better than just skipping to the new version.

Mary and Tom Poppenieck have greatly captured so many aspects of software development and how to do those lean way.

Found this great excerpt in a book:

Principles are guiding ideas and insights about a discipline, while practices are what you actually do to carry out principles. Principles are universal, but it is not always easy to see how they apply to particular environments. Practices, on the other hand, give specific guidance on what to do, but they need to be adapted to the domain. We believe that there is no such thing as a "best" practice; practices must take context into account. In fact, the problems that arise when applying metaphors from other disciplines to software development are often the result of trying to transfer the practices rather than the principles of the other discipline.

So true. How many times you’ve heard software development compared to constructions or any other discipline?

I have finished reading the book and wanted to write a short review, but the best I could come up with is a list of cons and pros. Lame, I know, but this will give you a hint at least.

pros

1. Smooth introduction, complexity is added step by step
2. “Strict mocks are causing brittle tests” – more than that, it causes to get into the private details of execution, rather than overall design and behaviour
3. “Method strings are bad inside tests” – absolutely
4. “Mapping tests to projects” – very right decision to spend time on the subject and show a right example
5. One-test-class-per-feature pattern is mentioned (music to BDD fan ears)
6. Writing maintainable tests – critical topic that was covered
7. DRY in test code – in general I agree that an unnecessary duplication should be removed from the test code. But there’s a think line that should not be crossed – tests should be readable and maintainable. For that, duplication sometimes is necessary. This is the less evil for a bigger cause – readability and maintainability.
8. Row testing is showed
9. “Integrating unit testing into the organization” – a very, very useful chapter, especially if you have to pioneer the field at your work place. Personally, I wish I would read this long time ago.

cons

1. Tests naming conventions
2. Too much is dedicated to Stubs and manual Mocks
3. Chapter 5 - Isolation (mock object) framework is explained with Rhino.Mocks Record/Playback rather that AAA that is more natural
• Note: AAA sample is showed, but after Record/Playback, which IMHO is a wrong way of teaching it. AAA is more intuitive and sticks more than the opponent.
4. TypeMock promotion – Roy is working for TypeMock that is a commercial tool. He could definitely use an OSS framework to show AAA mocking framework, like Moq framework. In an absence of a free tool, I would accept TypeMock as an example, or as a part of available commercial tools. (Page 130 shows the distribution of popularity, and Rhino.Mocks with Moq are the two most popular free mocking frameworks). This was a promo for the tool… not nice.
• Note: I am not a big fan of the fluent naming TypeMock is using. Isolate.Fake.Instance<IWebService>() is two verbs that are not intuitive.
5. Naming conventions for tests – both unit tests and integration tests are suffixed with a single word “Test”. I would rather distinguish and use context “Spec” and “Integration” as an example.
6. One-test-class-per-class pattern – for someone who’s doing BDD this is an anti-pattern. One big test class is a smell. It leads to brutal test code that is not only difficult to maintain, but even understand from it what it is doing. Very typical to the classical TDD.
• Note: Roy has provided a tip on this, politically correctly hinting that not everything from the big heads (Meszaro in this case) is always an absolute must.
7. Assertion with Extension Methods to improve tests readability was not showed at all
• Note: IMO Assert.AreEqual(found, expected) is confusing. I prefer to reveal intent with a code like result.Should_Be_Equal_To(expected);
8. NO BDD SAMPLES – BAD BAD BAD. I strongly believe that just with classic TDD testing is not complete. BDD is the next step in the right direction, and skipping it entirely was a mistake.

Conclusions

If you are a newbie in TDD or just “checking it out” – go for this book, worth it. In case you already have experience in TDD/BDD, and you are doing it for a while, it will not add much to your tool belt. Either way, the book is welcomed, and I am excited that more and more of this kind of literature is becoming available for .NET developers. I only wish the next version will be written BDD style, right Roy? ;)

I was chatting with an old mate of mine, Lev  Ozeryansky, with whom we graduated together computer science about 8 years ago (man, that was long time ago, but doesn’t feel like that). He’s a great developer, with lots of experience. Yesterday we have finally met and chatted a bit (guess about what). Two things I heard bothered me a lot.

1. You need more than 2 developers to do pair programming and being effective.

2. TDD is a waste of resources (where resources are developers, money, time, you name it) and only possible in big companies.

Lev was doing TDD, but he was the only person to do so. Why didn’t this work for the entire company? It was considered a waste. Worse that that, it was mandated as a waste by the management to the point where developers believed in it. What a waste… Immediately I thought just about the blog published lately – management has got to buy into this and adopt, and it’s a developer role not to give up on change promotion.

As to the first point, about pair programming, well… Personally I am a huge fan of pair programming for multiple reasons (final code quality, knowledge transfer, overall design, better testing in place, etc). I agree that it is impossible (and from the psychological point of view even not always desirable for certain individuals) to pair a 100% of time, but even 2 developers in a shop will do a huge difference by pairing.

Along with that I am no longer surprised that bigger companies are adopting both. Not just because “they have more money to waste”, but since they have already “wasted enough to realize that something was absolutely wrong”. If I would be today in a position of a start-up, yes, I would think twice before throwing these two aspects into the game. In case of a running shop – no thinking. Just do it, unless you want to vanish quickly among piles of in-maintainable legacy code in the suffer-land.

On my flight I had a chance to finish reading “Code Leader” by Patrick Cauldwell. The book is a good source for ideas and concepts that “solid” developers should employ on a daily basis. Topics such as TDD, build vs. buy, CI, choosing the right tool for the right job, contract driven development, and much more.

The book goes over subjects showing tidbits of everything, and could be probably expended and extended at least several times more. But then it would probably become “Clean Code” and “Agile Principles, Patterns, and Practices” clone, which author probably didn’t want to create.

Overall, I liked the book as an introduction to so many “Alt .NET” concepts in a single source. What I missed in this book is the human leadership in the code, the human-factor in code creation, the behaviour and interaction between people that work on the same software. IMHO, code leadership is not only superiority in machine code, but also in the team environment.

I am on my vacation, and not suppose to brag about software, but something has happened on my way to Israel, that just couldn’t go away silently. To get from Calgary to Tel-Aviv, I had to fly with Lufthansa for 9 hours first. The Airbus 340 is a decent plain. It’s flying, and it’s as comfortable as a Economy class can be. What blew me away was the entertainment system. Let me break this down.

As an airline customer, I want to be able to watch the movies on board, so my time on the boring flight could go faster.

Does this user story sounds too much to ask for? Nope, I think it’s a decent business case. As a customer “trapped” on board for more than a couple of hours, constrained in movement and in general ability to do what he/she wants, should be able at least to freely select a movie to watch from a limited list that is provided. Not in this case.

First, the whole entertainment system crashed twice! (I apologize for not using my own image I took with my phone – the battery died on me and I wisely forgot the USB charger:).

Was that an end? Nope.

Second, when the system finally came back – any selected movie would yield “The selected content is not available at this moment”. Awesome work folks. Just what a client needs.

Good that some people are hacky enough to go into flight information (crappy video with status of the flight) and at that time start zipping channels on the armrest (on the right side). That, surprisingly, was able to flip through the channels where movies were playing in an endless loop. Ha! Some entertainment, ladies and gentlemen.  

Moral of the story – quality is just not there. To understand if your software is worth anything, become the client of your own software. Being techy is not enough. UX and usability are as important as the software itself. Bring value and not shame on our profession – that’s one of the things I realize in encounters like this.

PS: Talking about usability – same entertainment system, the volume buttons seemed to be switched. Louder button was on left, and quieter button was on right… weird :)

Today, my friend Ran (no blog – boo!), has gave me a chance to feel what it is like to fly. Unfortunately, the weather conditions were not the best, and we could not do a lot, but the time spent up there was awesome. Feels great, and I wish I could do it more. Who knows, maybe I am discovering a new hobby in exploring the Z dimension :) Either way, a few pictures worth a long blog post.

PS: When we were about to leave, another flying craft appeared, “showing off” some nice stunts. As I learned later, it was a retired F-15 pilot. Another guy showed up as well, not flying, but getting his plain in the air. Hobby that is an obsession.

Stealing Rans' signature borrowed from Leonard Da Vinci I will finish this. "For once you have tasted flight you will walk the earth with your eyes turned skywards, for there you have been and there you will long to return."

In software like in a real life, not always everything can be extremely simple. One example I can think of right away is Inversion of Control container (IoC). In a simple application, it’s not a big deal, and normally achieved easily. The dependent component leverages some sort of Static Gateway container to resolve the dependencies based on contacts.

   1: public class Component

   2: {

   3:     public Component(IDependency dependency) //...

   4:     public Component() : this(DependencyResolver.Resolve<IDependency>()) //...

   5: }

In order to “populate” container with all the dependencies, normally we’d leverage some sort of start-up task to achieve the goal.

   1: public class StartupTask : ICommand

   2: {

   3:     public void Execute()

   4:     {

   5:         DependencyResolver.Register<IDependency>(() => new Dependency());

   6:     }

   7: }

When does the complexity creeps in? When a real life scenario kicks in. One of those scenarios are services. Why services? Because now it’s no longer a linear execution (a service can be started and stopped), and we neither want to pollute the service code with start-up tasks’ responsibilities. Solution? Different ones, but either way, a bit of complexity is added and from that moment and on developers are required to “ramp up” in knowledge to be able to understand and maintain it (develop or just-keep-alive). This is where “with power comes responsibility” is mostly used.

So is happening in real life. I was quiet surprised to see the most unexpected place – kids playground.

Playgrounds in Israel are mostly for kids up to age of 6 and not extremely attractive for teens.  Despite unmatched age, those normally spend some time at playgrounds as well, ruining them completely. A bright idea that a wise man had was to introduce “work-out” machines side-by-side with kids playground, so teens would invest their energy in a more peaceful way. Boy it worked! Not only little kids now have playgrounds in normal and usable condition and their parents a peace of mind, but also the awareness among teenagers for physical fitness has significantly raised. Well done. Here are some shots of proof how with power comes responsibility.

I am about to leave for my vacation and I think it is a perfect timing, based on what I saw this morning outside :)

Update: 2009-06-03

TortoiseSVN is a good tool. I like the frequent updates and good integration with Visual Studio through VisualSVN. What I find annoying, is breaking changes with no immediate follow-ups to fix those. Now it’s the missing key shortcuts. I prefer keyboard to a mouse, so in my case it’s a waste.

Please bring it back.