Returning to this idea, i realized that,increased releasing or increased deployment frequency has a beneficial effect on the overall velocity and quality of the release or deployment, while also improving team morale.

Because of this, I’ve been trying to create and respect strict deployment schedules, matching every development or bug-fixing iteration, namely(and usually)… every week.

It’s hard at the beginning and the first 3-4 iterations are tough (testing and deployment continues through the night because of inefficient planning and scoping) but after the team gets into the rhythm releasing and deployment becomes a trivial and actually fun activity.

Frequent release and deployment cycles also have a tendency of raising customer trust levels and wining some points for the development team, so release fast, release often, release good… and you’ll constantly get better results.

It is a known fact in software development that customer involvement in all phases of the project greatly increases the chances of success. Having the customer work together with your team gives them a greater sense of ownership, increases their interest and will ease the way to acceptance.

Customer immersion is not a dirty secret; the acceptance is not eased because they get a greater sense of ownership, it is eased because you are actually doing what they want. While working with the customer’s project team, during long projects, you will undoubtedly start to know them better, especially the team members that tend to interact often with your team. Nurture this interaction, accept them as part of the team, be honest and always respect their opinion. Remember that they know what they want and your job is to help them achieve their objectives.

Having said that, I have to warn you about two things: first, fraternizing only works on long term projects (I’m talking years… not months) and secondly, it must be genuine. Trying to fake friendship and involvement is a cheap trick that can be easily seen and that will turn them into enemies.

Together from day zero

Spend as much time as you can with the customer’s team at the beginning of the project. It’s that easy!

Photo by imcomkorea

Even if your customer is on the other side of the world, that is not an excuse – get laptops, get on a plane, work with them. If it’s in their offices that’s even better. I am writing this from my hotel room in Baku, Azerbaijan, after spending the entire day with the customer discussing and planning the start-up of a new phase of a national project.

No!, sending a team of analysts does not qualify as “quality time together”. Prove that you are on the same boat by bringing as many team members from as many disciplines as you can.

Quality time together will help create a bond between your teams and it will put the project on the right track. It will give your team the opportunity to prove that you are the real thing and most importantly it will:

• give you a valuable insight on your customers inner workings
• have a great project start-up together and thoroughly note their expectations
• allow you to adapt to their culture and filter out 80% of the misconceptions at minimum cost
• have your team meet the customer’s team so that in the future, when working together, even on critical incidents they will be able to communicate more effective because of familiarity
• exchange contacts securely and directly – detect and familiarize yourself with those key members that we talked about in Inception, or what you do before you begin

I you run an agile shop, have iteration zero together. Show them you mean business, involve them in the process, immerse them in the design phase, build a macro road-map together and position some stories. Demonstrate what you have achieved together in the first review and then…

Enjoy the fruits of your labor

A key factor of productivity and success, both personal and work related is celebrating.
Celebration and dissemination of success is a key technique that, when used properly and correctly, will advance your project, create long-lasting and successful collaborations, reduce stress and prepare everybody for the next big step.

Celebrating you success together, even small breakthroughs, beyond creating a bond between your team and the customers team also:

• gives an overall sense of good, the “closure” needed to proceed to bigger challenges
• proves that your mission is not impossible and that by working together you can accomplish anything
• proves to the stakeholders that the project is advancing
• bigger success stories are perfect for large scale dissemination, getting the project out of the hidden corner and into the light

You can celebrate together by taking the team out for drinks, having a small in-office party or just by having a time-out and discussing what you have just achieved. It all depends on the size of the achievement.

After the celebration, send an email to the customers team leader, project manager or even general manager stating what a great job their team does and what their contribution was to the achievement. Don’t overdue it and don’t CC or BCC the team, their manager will let them know, in his own way.

Shoot the messenger

Give them a direct channel for communication. If they want to get in touch with you, make it easy for them.

Give them your phone number and always answer. If you really can’t answer when they call, have an internal non-official maximum time of response and stick to it. If you’re doing something else, excuse yourself, answer and tell them that you will call them back as soon as possible.
If they use instant messaging or Skype, get an account and talk directly to them, whenever they need you.

You will be surprised of the long-term effects. When you will need them, and you will, they will also be available for you. Fixing dodgy or unclear issues will be a breeze, by avoiding emails and the incident tracking system you will win time, clarity and in time, friends and allies.

Mutual help and lasting relations

By following this simple set of rules, I have gained friends in every project that I have ever worked on, people that I still interact with and help and that also help me when I need it, be it introductions, references or even the occasional hotel reservation in their city. I enjoy meeting them and I always enjoy working with them.

Some of the topics expressed here will be elaborated further in my The lore of delivering software products series so stay tuned in for more information.

Noun
S: (n) origin, origination, inception (an event that is a beginning; a first part or stage of subsequent events)

Inception, the first article in my The lore of delivering software products series presents one of the key phases of a software project, a phase so important and sensitive that it alone may decide the final outcome of the project: success or failure.

This is a phase of discovery, acquaintance and assurance both for you, as a provider and for your customer, which so anxiously awaits the day when he can reap the fruits of his financial and social investment in this new project.

This phase is the one that lets you see if the customer is fully involved in the project and is really ready to go the extra mile with you to see the project delivered; this is the phase that tells you if the customer really cares about the project, the product and the benefits that it will bring to the general end-user population, or if this project is only done just because it should, because the budget is there and because people really need something to do and a project is a good thing to do, over and over again.

All or nothing

As we all know, there’s a mythical ratio that everybody avoids mentioning in project meetings or project briefs, namely “two thirds of all software(system) projects fail”. It’s true, they do, but I’ll let somebody else write the series on project failure.

Photo by conray

Now, as we know, failure is a very relative term in the software development and integration world. A project can be successfully implemented and used on a nation-wide level while being a huge failure for the company that implemented it, because the costs were 200% more than the contract value. Eh, they’ll be able to use the good references and maybe, in the future, they’ll learn from their mistakes.

Most software projects fail in this phase, which is a good thing, if you want to fail, this is the best phase to fail in, and there’s a good reason for that.

In this phase, your investment, as a provider, will be minimal and – wait, let me rephrase that – your investment in this phase should be minimized, always. Under no circumstance will you start developing the product or purchasing required hardware, software or services. Nah, wait until you have a solid grasp of the project and until you’ve met the customer.

During this phase, your senses must be alert at all times, during all meetings with the customer and your partners, ready to sense any problems, even before any of them can cause them, because they will. If you feel that, even from the first meetings, the engagement of the customer is not up to the challenge, address this issue. If addressing this issue does not work, prepare a contingency plan… an exit strategy. Who knows, maybe you’ll need it.

If the engagement of your customer and your partners reaches your expectations, the project seems to be on track or it’s steadily getting there, you have a moral responsibility to take this project to delivery… and success, because quitting the project once you have completed this phase you cost you not only financially, but it will also hurt your image.

The real stuff

Enough with the chit-chat, and down to the quick and dirty business. This article is actually about what you should do to ensure that the project has a smooth start and that everything is on track.

What you do, as a service provider, is the most important part of this phase. You are responsible for planning and executing most of the activities of this phase. Most importantly, you are responsible with the engagement of the customer and partners in these activities. If you are not the prime contractor and you see that they’re holding back, your main task is to engage them and to make them realize the importance of this phase.

- Be professional, be polite, never over-commit and under-achieve
- Just as you can, the customer can prepare and execute an exit strategy and find another supplier

The activities and outcomes you must target

In this phase there are some things that must be accomplished just for the sake of it and there are other things that are really important and can decide the fate of the project. Just like in life, the ones that really matter seem to avoid the eye.

Activities and deliverables for this phase are split up into two categories:

1. Important to your customer (will actually make their day happy):
- Interim project plan, or working with them on the project plan. A third of the project should be enough. Remember, we’re talking macro planning, a WBS 3 levels deep. Details spoil the whole thing. You know that you’ll have to deliver the final plan sometimes soon, so why not involve the customer in the process.
- Quality assurance, the magical term stating the fact that the project will be guided by quality and that quality assurance procedures will be part of every activity. You know, like testing, standardized work, proof reading, that sort of thing. Yes – you got that right – proofreading documents. Don’t put it in the plan. Just do it!
- Promotion (dissemination) plan. If it’s a big project they’ll want to show it off. You’ll have to create a visual identity, advertise it on TV, have press conferences and go to international fairs and summits. Who knows, maybe it will increase your business in the vertical, it usually does. When you disseminate, do it by cellebrating your achievements with the customer’s team, and letting everybody know.
- Knowledge transfer, or how the French would put it “transfert de savoir-faire”. You have to do it. I know that vendor lock-in is really sweet, but transferring the know-how to your customer will save you a whole lot on maintenance, technical support, upgrades and it will give them the sense of independence and self determination that they desire internally. This is a real gem, and I’ll talk about it in detail in the future.

2. Really important, even critical for the outcome of the project:
- Identify the internal apparatus of the customer. This is really important! You have to identify the organizational chart of the customer, in regard to this project, the mirror image of your own organizational structure. The most important positions to identify are: who will oversee delivery, who is the person that will give you access to the end-users (this is really important), who is the main stakeholder, the project owner on behalf of the customer, the one that really cares. Usually, the people that hold the power are not the apparent ones. The project director on behalf of the customer will only sign the delivery if one of his aids will give him the technical and business approval. Find these people, as you will really need them during the project.
- Communications plan. Who you talk to, what will you talk about, how often will the meetings happen. It’s a project buster! Having a good communication plan, accepted and executed by you and the customer will ensure that you’re on the same page, all the time.
-The kick-off.The meeting that says it all. Have your team meat with the customer’s team. Show them what you’ll be doing for them. Do it clearly and slowly. Use graphical means. Don’t scare them away. Include everything on this list, even as bullet items. Get a feeling of the customer’s team. Are they into the project?

All of the things above are coming from a pragmatic perspective – just sharing with you what works – not a project management one. Maybe a full blown project manager will have a few more plans or a few more activities up his sleeve or maybe your project has these activities set in stone, some do. The bottom line is that if you cover all aspects but always keep an eye on what your objectives are for this phase, then you’re on the right track.

Your objectives… achieved

To conclude, your minimal objectives for this phase are:

• Get to know your customer and your partners, make them your friends and allies
• Show your customer that you are professionals and that you are at their disposal
• Have a project plan, at least for the first third of the project
• Identify the internal apparatus of the customer. Identify the people that matter
• Setup a clear and concise communications plan
• Have a kick-off, meet face to face as often as possible
• Never over-promise and under-deliver, especially not in this phase!

If you achieve these objectives, you’ll be on the right track to a sustainable project, where all parties are engaged and willing to give their best to produce a great, usable and long lived software product.

Some of the topics expressed here will be elaborated further in my The lore of delivering software products series so stay tuned in for more information.

Jamie Zawinski, as quoted in “Coders at Work”, elegantly summarizes everything that I’m trying to express:

“At the end of the day, ship the f*cking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

This is not a series about programming, using a specific framework or development methodology, although it includes bits of everything.This is a series about improving the way you work, focusing on the project at hand and delivering great software on time, on scope and on budget.

This series encompasses the lessons that I’ve learned by repeatedly hitting my head against problems with projects, people, processes and occasionally, my own stubbornness.

Photo by Damon Duncan

Series articles (list may change):

1. Inception, or what you do before you begin
2. Fraternization, or creating friends and allies
3. Fixed scope, or the holy grail of software development
4. Dangers, or the risks of the trade
5. Genesis, or coming into being
6. Shims, or the tools of the trade
7. Construction, or getting it done
8. Quality, or the other part of construction
9. Spells, or handing over the knowledge
10. Done, or how “the best is better than good”
11. Covenant, or what happens after you’re done
12. Phoenix, or rising from the ashes

I’ll try to publish one every week, starting with this week’s article, “Inception, or what you do before you begin“.

Feedback is welcomed, bad feedback even more.

Brief history
GUtil! was born sometime in 2006 and I released the first version (GUtil! 0.4.9.5) on November 3rd 2006, for Firefox 1.5.

At first it was something that I used to speed up access to the Google tools that I was using so I only had a couple of links. Then somebody asked for it and also asked me to add some more things that he used. So I did. And I published it. And more people wanted it. That is all.

Current status
I haven’t touched the code since July 30, 2009.I’m not using it anymore. I have restricted my Google usage to Google apps, Picasa and Reader.I don’t care about anything else, nor do I have the time to care about anything else.

Some statistics:
- GUtil! has been downloaded 240,651 times
- GUtil! is part of 198 collections on AMO
- GUtil! has 8680 active daily users down from more than 12000

Future
Well, here comes the bad news.
I’m not updating it anymore. I don’t have the time, the patience or the interest to update GUtil! anymore.

If you want to work on it, it’s always been open so go get the source and have a whack!
http://code.google.com/p/gutil-firefox-extension/

All the best to whoever wants to continue with GUtil!

Photo by katerha

Last year’s recap:
- Quit smoking: done
- Learn Turkish or Arabic: not done, moved to 2010
- I try to learn a new language every year. 2009 was C# year: as done as you can learn a language in one year

So… my resolutions for 2010 are (drum roll):
- Learn Turkish or Arabic: hopefully a new project I have in Morocco will help me learn some Arabic
- The new language for this year is Scala
- Buy a car for the wifey
- Deliver better software

List types = new List();
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();

foreach (Assembly asm in assemblies)
{
        IEnumerable asmTypes = from t in asm.GetTypes()
              where t.IsClass
                && (t.Namespace != null && t.Namespace.StartsWith(targetNamespace))
              select t;
        types.AddRange(asmTypes);
}

I actually got to this point because of the way NUnit wraps an assembly in another AppDomain.

The snippet need Linq so it’s for 3.5 or newer.

Sometimes, you’re just having a wonderful day and suddenly the worst just happens:

[ServiceController] Problem starting service jboss:service=Naming
    java.rmi.server.ExportException: Port already in use: 1198; nested exception is:
    java.net.BindException: Address already in use: JVM_Bind
    at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:243)
    ............

The regular solution is to check if the port is actually used. So fire up a command prompt and netstat –aon.

If you find the port, see what process is using it and kill it .

If you don’t see the port you can reserve it by following the information in KB812873 – http://support.microsoft.com/kb/812873.

My ReservedPorts entry contains:

1433-1434

1097-1200

4543-4545

That should fix it. The bad thing is that it requires a restart.

As time flew by, I started to get a taste of what .NET is all about, luring me to the dark side.

Photo by B-tal

At the beginning I felt like “this is what evil must taste like”, but I quickly got accustomed to all the new things and now, I’m playing with .NET stuff again, mostly C#, trying to level my skills and having a lot of fun in the process. I built things like the quick and dirty multi font viewer, buggy and poor, mostly because nobody uses it.

Now, I wanted to start something bigger, and nicer (I won’t say what) and I felt that I needed to do it the right way, you know, MAINTAINABLE.
I started looking for a DI container and I started with Spring and Pico. I’m pretty accustomed to pico and I’ve been using Spring since version 1 so I though I’d give them a try. Wrong, strange, alien, weird, huge, EVIL.

For what I wanted to do it really seemed this way. How’s about something that is 10 megs big because spring and dependencies is 7 megs big. And I’m not even going to use most of it, I just want some plain dependency injection and maybe some tooling , like fast i18n.

Problem solved, evil destroyed
I found the solution! Why not have some fun AND learn the inner workings of C# and .Net? Why not build my own? So I did!

NanoDI is a small dependency injection container and tooling for .NET C# projects that are small or that do not need the complexity of bigger IoC solutions.

NanoDI‘s goal is to be small, fast and clean.

Links:
Nano Dependency Injection home
NanoDI Ohloh.net project page
NanoDI Google Code project

The code is junky by my standards but I’m slowly refactoring as my c# skills get better. Next week I’m going to finish scoping and start working on proxies and interceptors. You can help too!

Have a taste, have fun!

Writing transactional unit test with JUnit, Spring and Hibernate is easy, what you want to do is:

- Add a transaction management bean in your test context:

<bean id="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>


- Make your test extend AbstractTransactionalJUnit4SpringContextTests
- Annotate you test class with @TransactionConfiguration and @Transactional

If your transaction demarcation is correct( surrounding your dao or service ) you should be done. This is the cleanest way that I found.

Everything until now is fine and dandy. The problem arises when one of the injected beans is bound to a scope. It can be any scope but for this example I’ll take the simplest scope – the ‘session’ scope.

In a non-transactional situation this should be pretty straight forward, just implement Scope and using a ConfigurableBeanFactory register it. The fact that we are extending and that our context is automatically created really kills the simple path.

You’ll get a org.springframework.beans.factory.BeanCreationException with a nested “java.lang.IllegalStateException: No Scope registered for scope ‘session’”.

But do not despair, there is simple solution available and it’s called CustomScopeConfigurer.

The fastest and cleanest way to use it is:
- Create a simple class that will be used as our scope manager. Let’s call it MockSessionScope.

- In your test context, create a CustomScopeConfigurer that will automatically register your scope on context creation:

<bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
<property name="scopes">
<map>
<entry key="session">
<bean class="com.gridpulse.xandria.translator.MockSessionScope"/>
</entry>
</map>
</property>
</bean>


Run your tests and you’re done!