Sunday, August 30, 2009

My development Tools

In an average work week I use:

Visual Studio 2008 Team Edition: The IDE of non-choice.

Reflector: There is no excuse for not having this if you work with anything that you haven't made yourself. And even then....

Resharper: Can't live without it. If you develop in VS2005/VS2008, professional version or higher, you should waste no time in getting this. This is a plugin which makes Visual Studio what it should have been in the first place. Microsoft is usually very slow to establish accommodation for sound development practices. And even Resharper is a wee slow for being the testrunner of choice.

NDepend: I love this tool. Have you ever wondered how to manage a large code base without actually having to read every single line of code? Then this is it. Also pretty straightforward to integrate into your build to enforce architectural constraints.

Redgate SQL toolbelt: We have a lot of stuff going around SQL Server. Even though I have database edition of Visual Studio, redgate are the ones that seem to actually have experience in the problems of managing such servers.

ANTS Profiler: Wanting to get to those hard-to-find and hard-to-reproduce performance issues? With very little overhead you can have it running. And, if you are able to reproduce it, you have it. Too many performance tools require you to predict exactly when you are going to see the problem. ANTS Profiler allows you to capture all, and then zoom in on it on the timeline.



Other stuff:
* Mindmanager. (when you just want to get those thoughts down)
* Expresso. (regex helper)
* Editpad. (notepad on steroids)
* SPX from Moodysoft: (screen grabber with redlining and visual effects)
* Zoomit. Every presenter need this when sharing desktop with a projector.

The debate is over, TDD won.

I find that I have very little to add to the words of Robert Martin (Uncle Bob).

I highly recommend people to look at the available videos of him and his talks about professionalism.

Our profession as programmers is very much immature. We have hard to accommodate accountability and transparency. We have little regard of what constitutes a true "Deliverable". And, to paraphrase Ken Schwaber, we have a very odd understand of what it means to be "done".
http://www.hanselman.com/blog/HanselminutesPodcast119WhatIsDoneWithScrumCoCreatorKenSchwaber.aspx
Basically, we like to do the algorithm, but we do not like to bridge the algorithm to the world.
A nice analogy is the difference between a hobby mechanic and a professional service business.


We put juniors in our office space and we expect them to produce.
Even a person operating the fryer at McDonalds gets some sort of apprenticeship.

We resist change. We resist being scrutinized. We resist being managed. We seldom recognize business value. We resist comparison.
We do not have objective standards or engineering principles. The only professional criticism from programmer to programmer is "that's not how I would do it".

http://www.hanselman.com/blog/HanselminutesPodcast171TheReturnOfUncleBob.aspx


But there are standards to be had. Engineering principles exist. But I sincerely do not know if you will actually appreciate them if you have no experience in the industry. I have yet to see this successfully condensed into a learning experience that mentor can bestow on apprentice. Or in the class room.

Uncle Bob has the comparison of when doctors learnt to wash their hands when walking from an autopsy to the maternity ward. It took a generation change to implement it. And the problem domain was unknown to anybody fresh out of the contemporary version of "med school". One may even argue wether or not it still was the same profession before and after knowing about germs.

Even though I don't think a serious argument still exist against Test Driven Development as a whole. It is still an immature practice which a significant part of the developer community still resist.

Without a frame of reference, it is hard to separate the community from the practices. It has become a part of the expected norm that software has bugs and that software development is an inherent financial liability.

I believe and hope that this will change.

Just fifteen years ago (being careful to pick a timeframe that excludes me), programmers were stereotyped to be socially awkward, cave dwelling magic workers with questionable antics and hygiene. Approachable only by the specially trained project manager who knew better than to hint at a questionable decision or belated milestone.
Today, most project managers are quite capable of programming in MS Excel and the sacred art of programming "magic" has unraveled.
Even though I presented a caricature strawman, something has certainly changed.

I hope that they will keep changing. That technical debt, development liability, Test Code coverage, Continuous Integration and automated deployment will be common case real life business metrics KPI's (Key Performance Indicators) for the future.


The debate is over, TDD won. Will the community inertia demand another 15 years before the change is de facto?

Skepticism and mentalism.

To me, skepticism is about observing the world and then build your knowledge.

I love the fact that outspoken atheists like Richard Dawkins have started to connect with the likes of Derren Brown. I believe James Randi has a big part of that credit. I think that this was an important pragmatic step for skepticism.

I do, however, find that fellow skeptics are less comfortable with that. For example, to me, the "placebo effect" is something wonderful that we should celebrate and try to isolate and purify.
However, my peers usually find the placebo effect (is there any other human intellectual endeavour where you decide to name an effect after the one thing that you know to be irrellevant?) to be a reason for dismissal. I strongly disagree. I dismiss pretty quick the explanations given (aura, holisticism, spiritualism, deities), but I recognize skills and recipes and I am fascinated by the mere fact that the body can heal itself (or at least: stop behaving symptomatically). If I could invoke the "placebo effect" at will (without mumbo-jumbo) I would prefer that to taking a pill against normal headache.

My own blog

Somewhere along the way, I realized that I victimize my coworkers by the water cooler by bestowing my idea of "interesting conceptual problems" on them. Usually this means that the problems have no real-world application or even relevance.

The blog allows my banter to be victimless. And, since I don't yet have readers, I suppose the subjects will be all over the place.

Maybe even somewhere along the line, I find that someone is willing to give me feedback other than "huh?"


Now about me....

I am an outspoken freethinker and atheist. I pull few punches when it comes to discussing subjects. Sometime in the future, I hope to learn to listen as well... When I find time for it, that is....

I am an active athlete in underwater rugby (coach and team captain) and an avid amateur on combatives. I have done some instructing on professional application of force as well as self defence and I am pretty good.

I have a best friend who is a hypnotherapy phenom. I love discussing mentalism, hypnosis, NLP and mind states.

I am a programmer in C#.NET. That's me for the moment. Not that I don't recognize Java, functional programming or dynamically typed languages. But I find that they expand on a tangent that I'm not "into" right now. Hopefully that will change when I get good with my current programming domain.

I am well into popular sciences.

Come to think of it, I sure hope this blog engine support tags so that I wont lose .NET readers due to my banter on hypnosis. Most blogs that I follow usually are all on the same theme.

The reverese dependency problem. TDD

When building the word chain app, http://codekata.pragprog.com/2007/01/kata_nineteen_w.html , I quickly identify that there are multiple problem domains involved. One is the generic question of finding the shorter path in a mesh of connected nodes.

Then the question is: do you build this functionality with its own set of unit tests or not?

I would like to say "not". I don't want to take "time out" from my real business problem to build a different class library in some BDUF venture. I want to refactor into this design.

However, let us say that I proceeded with this, and elegantly refactored a utility class library that was generic and succinct.

And then this class library is so generic that I have more client apps that should be consuming it. And new clients warrant more functionality.
I may not be able to express new client requirements from my wordchain problem, and therefore I need to TDD from the unit tests of the new client apps.

However, then the class library, slowly becomes "dependent" of a growing number of its clients, because that is where its unit tests are. It wont get coverage unless you run the unit tests of its clients.

I realize that at some point you must recognize that the new class library is a new "deliverable" and thus you need extract its own tests. This will however result in duplication and longer release cycle for the word chain app, because it is a separate release item. New word chain app requirements will have longer development time because new requirements to the class library must be TDD'ed through unit tests of the class library, parallel to the unit tests of the word chain app.

Theoretically, you should have 200% percent coverage in the class library. One "100" through the sum of its clients unit tests, and one "100" through its own unit tests.

Interesting problem. It becomes sort of a reverse dependency problem. Stabile components become dependant of unit tests of less stabile components.


Do you find that you get test duplication because you don't want some internal class libraries to be "depending" on the unit tests of its consumers?