Uncle Bob stirs the pot again with "Dependency Injection Inversion"

Uncle Bob posted what was considered a rather controversial blog post, which basically pointed that just because Dependency Injection is a good thing, does not mean you cannot shoot yourself in the foot with the DI framework. He drew attention to the fact that these frameworks in their desire to be more usable have all kinds of bells and whistles, which you might just stop and think about before you jump in and start using them.

My initial reaction to this post was very positive since I always have considered the DI container something external and (potentially) replaceable. Looking from a DDD point of view (I tend to look from that one, don't I? ;) it is infrastructure which is not central to my apps, which means it should not be meshed with my core code. Hence my tweet:

I liked the point he made: you see, you can do Dependency Injection without a container. I would add, I think everyone who is doing Dependency Injection should do an exercise once in a while - write a small app without a DI container. There are two points in this exercise: one - to make sure one remembers the point Uncle Bob made, and two - to appreciate the DI containers.

Towards the end he says:

Most of the time the best kind of Dependency Injection to use, is the manual kind. Externalized dependency injection of the kind that Guice provides is appropriate for those classes that you know will be extension points for your system.

Not so sure how I feel about this one though. Most of the time I do use DI container unless the app is very very small, but unless I try I will never know, right ;)

Interestingly enough the .NET alpha-geek crowd jumped(and again and again) Uncle Bob on this one. Agreed with him for the most part and bashed him for the quote I just mentioned as well as for his example being too simplistic. I feel they are being a bit arrogant(bashing the Java tooling and all that) but they do have a point though. What do you think?

24.01.2010 | Comments [0]
Flokkur: Agile | Forritun | XP
Höfundur: Petar Shomov

Lessons learnt the hard way

I just got off a large project that one of our customers is running. I will not go into details but it should suffice to say that it is a rather large multi-phase project that is supposed to create the future IT backbone for that customer. Before I move on I though I should stop and analyze what we did right, what went wrong and what can I learn from this experience. And I thought I would share it with you dear reader ;)

1. Deploy by the end of the first month to a user
In large companies there are usually many reasons why a project cannot be deployed: dependency on another project which in turn depends on another project and so on, or someone has to get legal approval for something to be released. Yes, there are many excuses not to deploy, but in the end that's all they are - excuses. The business needs to see value, your team needs to get feedback from real users about the system otherwise you are risking building something no one is interested in and/or the business people loosing their business patience. My future rule of thumb would be - if you have not deployed to actual users by the end of the first month of the project, you need to do get angry and demand this to happen right away.

2. Do not accumulate technical debt, push back on Product Owner who does not understand technical debt
Technical debt(from here on referred to as tech-debt) is hard to explain to product owners that have not programmed. This is understandable and there is no easy way around it. We tried all kinds of metaphors but I don't think we succeeded in communicating what tech-debt is and why it is important. The best approach that I can see working is to negotiate a slice of each sprint to go into paying off tech-debt and demand extra on top of that at the first sign of trouble. Letting it pile and telling yourself that it is ok, that you are going to fix it "later" does not work. Never has, not for me. "Later" the debt is usually so big and the bad stuff has usually spread all over the place and fixing it becomes an all-or-nothing mini-rewrites that are very hard to do and are rather unpleasant and unsatisfying experiences.

3. Do not allow architectural astronauts to tell you what tools to use
It is a strange phenomenon but seems quite persistent: a company becomes mid-sized and someone decides that now they need to unify "how we do things around here". And then an Architect (may be even Chief Architect) is appointed who starts googling and creating a list of tools and technologies allowed to be used. And this is the moment when you start to be told what tools to use to do your job by the guy who has never done your job or it has been a while since he has last done your job. Do not let this happen, say "no" to company politics and demand that you decide what tools to use. The list of tools should be coming from you and the rest of the guys that are working in your organization. Architects can be valuable, but this is not the way. Do not buy into tool vendors based on power point presentations and one day carefully orchestrated demos from the salesman. You and your peers should be making the standard in your company. 'nough said.

4. Manage expectations so that they are achievable
I have come to appreciate marketing as a *very* important aspect of product development. The same product may be perceived as two complete opposites depending on how its being marketed. One thing that I've found out is not wise, is to proclaim that your product will be a universal panacea that will fix all there is to fix. This might sound obvious and plain common sense, but I am mentioning it for a reason: the larger the promise you make, the more difficult is to keep it. So I would advise to do small achievable projects and build software products incrementally and iteratively. And the product owners have always to be on the lookout how to generate value with minimum effort.

Well, I am off to the new project ... ;)

02.10.2009 | Comments [0]
Flokkur: Agile | Forritun | Scrum | XP
Höfundur: Petar Shomov

The Decline and Fall of Agile

James Shore posted an excellent blog entry titled The Decline and Fall of Agile about what he's seeing happening with many Scrum teams, provoking a myriad of responses all over the agile blogosphere.

A few of the posts:

Robert C. Martin (Uncle Bob)

InfoQ

Jeremy Miller:

In my opinion, Scrum is a kind scaffolding around the team where value is actually created, used to construct the real process, one improvement at at time. And, if you know where you can go, those improvements should lead more or less towards XP engineering practices. The reality is that Scrum is a lot easier to sell than XP in its entirety, especially when it comes to getting people to rally around a process change to begin with. XP, on the other hand, with its 12 practices, can be mind boggling to start with if you don't have a coach who really knows the drills.

People, knowing only Scrum without the technical practices to make shorter cycles work in the long run, are going to get into trouble. It's as simple as that. Of course not everybody is going to be equally good at it, but awareness is a key element. If not believing something is possible makes sure it won't happen then not knowing about a possibility is an even better way to ensure it never happens. So introducing Scrum as a complete package into a company without at least ensuring awareness of the technical practices, is a risky practice IMHO.

We are fully aware of these risks here at Sprettur, and are ready to provide training in the engineering practices talked about in these posts. Contact us for details.

17.11.2008 | Comments [5]
Flokkur: Agile | Scrum | Sprettur | Stjórnun | Tækni | XP
Höfundur: Guðlaugur Stefán Egilsson