Self improvement - putting your neck on the line

What are the things that you like most at your work? Some techies might say it is debugging a really wicked algorithm, some may say it is really about talking to a customer and finding out a solution to his problems, others will mention that leading a team into success is what really makes them tick.

For me... learning is what really motivates me. Going out of my comfort level. It may seem hard at first shot but over the years it has shown to be what really makes you getting better on what you do. Accepting every challenge with a strong believe that you'll be able to overcome it...

Being in a constant state of knowing that you don't master what you're about to do, makes you excel in trying to find the better way to do it. And it turns every minor successful task into a major achievement.

Of course, being surrounded with people that push you to push yourself and are there to help you succeed or support you when failing helps a lot. A culture of experimentation and constant improvement is key to keep the innovation coming. Don't be afraid to fail... as long as you fail fast and learn from it.

2010 Review

Everything changes but change itself. -- John F. Kennedy.

A lot of things went on in 2010. And very fast.


Going a bit back in time, "Change" is everywhere in my life. I learned how to embrace it well some 15 years ago when my father passed away and our whole life as a family had to change. I had been doing some Spectrum basic programming, so even before going to university, I started working for a person that was addicted to lotto. I started doing Access software to calculate probabilities over lotto. Quite funny actually! (All of a sudden the guy left everything he had and started sculpting as a way of living - personally, I think he won the lotto but never told me so he didn't have to share it :) )

From that point on I looked forward to new things coming, to new challenges appearing... But that was to long ago.

30	% improvement in the end-to-end claim resolution process time
338	change requests implemented in the first year of operation
12	languages supported and serving 16 different countries

Back to 2010, as the year was starting, I was still with a Dutch client, doing a major refactoring on its codebase. This is an insurance claims handling system, that was totally relying on a custom built light BPM system. It was not optimal, to say the least. We were able to refactor the whole thing, without never stopping operations, in an iterative and incremental way. BPT, the BPM from the OutSystems platform, was implemented. It was one of the most challenging tasks I have ever gone through. The business is not even aware of what went on under the cover. They just got it as "the new BPM", the tool to help them analyze and optimize the processes. That's how it should be.

We got an amazing set of patterns from there. The technology was so good that it was able to overcome the major BPM pitfalls. I put all that experience, cross-referenced it to my previous experiences with BPM implementations and set up a BPM training (using BPT for the hands-on). This was one of the year achievements I am most proud of. I've already lectured 2 in Portugal and one in The Netherlands. The feedback was great!

It also led to two great events:

• A talk in NextStep, were I shared a set of BPM best practices applied to a real life line of business application
• Winning an award on BPM and SOA, the Business Agility and Process Optimization enabled by BPM and SOA Case Study Competition, given by OMG. I went to Washington DC in order to receive it but, due to some fatality, Dr. Richard Soley, OMG's chairman was not able to be there, neither his replacement (that got stuck in the highway due to some guy shooting at the Pentagon). It turned out to be a good way to do some day walking, discovering the beautiful DC.

On the beginning of the year I was also hosting the Delivery Manager bootcamp. It is an amazing experience to do this kind of training. It targets those that are already managing delivery teams or are already very experienced in delivering projects. From role playing to Lego building, the topics are great. We get the chance to discuss a lot about software architecture, Agile management skills and responsibilities and exchange real life experiences from real life projects. I'm enjoying this coaching side of my job and will surely invest in it.

Then the big news came. I was offered the role of Head of Product Development for the OutSystems Agile Platform. I'm now following up the excellent work done by Kutuma and trying to figure out ways to make a great team even greater. It turned out to be a big transition; going from a Services unit, where I was mostly delivering business solutions, to one of the most challenging roles for delivering a product in a product oriented company. The biggest change is that while I was previously 100% focused in helping a customer, I'm now with a much broader audience. Helping a specific customer request may not be exactly the best thing for the product.

My first release went very well. The team was really focused into delivering the most valued stories, in a very Agile way. It went to the street on 02.12 and we called it the "Try me in the cloud" edition.

All in all it was a great year. A lot of things changed... and for the better. I'm hoping 2011 will be as good as 2010, with this many experiences, allowing me to learn new things, from new persons.

And I wish you'll share that with me. 

Have a great 2011!

Software - The maintenance paradigm

Why is it that maintenance is seen as the boring faction of software development?
Why do all good developers usually end up creating the first version of a project, but as soon as it goes to production, we get a "secondary" team, usually with less experienced developers, maintaining it?

I think it is because the act of creating a new piece of software is seen as an art (at least by those creating it), whether maintaining it doesn't. As such, it is logical that you need the most creative ones, the ones with more experience to do it, so they can pick on what they've learned and apply it to the new project.

The fact is that if a developer participates in a project and, as soon as it goes live, he moves on to the next one (and this happens a lot in the software consulting business) you'll end up with someone that doesn't really know what it is like to have a system in production. How can he know that a "real system":

• requires the correct (not too less, but not too much) amount of logging, auditing, performance...
• has data, tons of it, always much more than what we expected/planned for
• requires some "circuit-breakers" in those special places so that some minor bug does not bring the whole system down
• needs refactoring, grows with refactoring, and that you need to look into all the existing data so that your refactoring is backward data-compatible
• actually has users, demanding users, sometimes those that never sleep

On top of that, a "maintenance developer" needs to do all of this... and on someone's else code. They need that special capability to reverse engineer a requirement just from the code, understand what the heck the guy who did it was thinking, and still cope with the users demanding fast change because the system they use all day is burning. These are the special artists!

I have one rule: when interviewing someone for a senior position, ask him how many systems has he got into production. You'll probably hear a number that goes up to 50, proudly. Now ask him how long has he maintained those systems in production. If he has no experience on that, I do not consider him a senior. Just as simple.

For consulting projects this is just as simple. If you're building software products there is one difference. If the products goes through several versions, these concerns become shared knowledge. Both teams (the ones doing maintenance of existing versions and those creating new ones) usually work in sync. There is even some rotation between them so they all go through the same set of concerns. If you don't have it on your teams... you should.

BPM pitfalls

In the last few years I've been working extensively with BPM (technology, analysis, industry development). I don't want to go right now into the discussion of whether BPM is a method, a technology, etc... more on that later. I'd just like to share some real life experiences on actual BPM systems implementation.

I started by implementing BPM systems in a low level view, working a lot with APIs, integration with applications, low level requirements. On top of that, I went through the mindshift people had to endure when analyzing these types of systems, and finally watching the real benefit they take from it.

My conclusions? There are a lot of small details, I'll go through them in the following posts, but for now a general overview of three major topics

1. BPM blends with an application

What is the point in implementing a BPM system if it is not supporting any line-of-business application? Just to make the process standard? You can do that without a system. Gather your collaborators, discover your processes, draw them on a paper (or in Visio or some open source tool if you're really into the technology thing)... because that is the first thing to give you the benefits of using processes. Having them drawn on a piece of paper and sticking it on the wall, so everyone is aware of what they should do, is enough to get you a 12% increase in productivity. Just drawing it (actually this is because by now you "know" the process; it is clear to everyone)!
So the real benefit of a "BPM system" is when it becomes an integral part of the system that already supports your business. When it allows you to measure, extend, prioritize the tasks that are already done in those systems by your collaborators. Having the two systems running in parallel might bring a benefit... but having it integrated really changes the way they work. If you're thinking on starting a BPM implementation think about how your system will integrate with your application. What will happen if you change your application? Will the process be inconsistent? What is the lifecycle of the application? Does the lifecycle of the process matches the application's? Will they go live at the same time?

2. Long lived processes are your biggest concern
How much time will your processes last? One support case might take a couple of hours, one installation of landline/DSL/internet/cable tv might last a couple of days, one insurance claim may last months. Suppose you break a leg on a car accident and call your insurer; what if after 3 years you still have problems in your leg? Won't the process to handle your claim still be alive? What about new laws that just came in; what about new fraud detection rules, what about new insurance companies conventions that determine that every claim of a particular kind should be handled in a specific way. Those changes need to be brought into your process. «That's ok» you might say, «the good thing in processes is that they are visually modeled, every tool allows you to change that model easily».
The thing is, on short-lived processes you can just create a new version of the model and deploy it. But on those processes that last for months or years you just cannot do that, you need to upgrade the current model, not a new version. And when you do that what will you do with all those instances that were already running in production (since the day you first called your insurance company)? This is a major challenge that is not usually addressed when we're starting our BPM effort. One that will become a major burden when you need to consider it.

3. Reporting/monitoring is the ultimate outcome
What's the purpose of using BPM? It's not about knowing the process (for that you might just use a pencil remember?). It's about monitoring it so you can optimize it, therefore reducing costs.
So you should make sure the process you  are designing is actually measurable. That you can look at the statistics your tool provides you and make the correct judgments. The problem is that this will many times lead you into making a process that is targeted for the reports your tool supports; lead you into making a process that is not business or technically the best design. But if you do it right, you might end up with imperceivable reports just because you added too many levels of subprocesses, or implemented a multi-role process as multiple separate processes to facilitate the integrations with the application or external systems.
My point it, you'll loose something on most occasions... my advise is that you should design the correct process and choose tools that allow you to build your own custom reports over the processes. That way you'll be focused on building the right process for the right occasion. And you'll still be able to analyze it properly

What about you? what were your major challenges in BPM systems?

Cutting features, motivation and appreciation

When building a product that requires some degree of innovation or creativity the persons involved in implementing it are the key thing to succeed. Specially in software products, that want to have an added value over some other product, the ones who create it really need to think "out-of-the-box", investigate and experiment. They will surely fail sometimes, but that is the process that will help them actually create something fundamentally different, better.

Now imagine you have a team full of brilliant people doing that. And they are actually allowed to experiment. They actually build great stuff... much faster than one is able to market and deploy. You'll sometimes have to choose to leave some of this great stuff out. What is wrong in this? Well, we ask for creativity, we get it, but then we need to keep them marinating until the time is right, or the prototype is perfect, or the market is ready to fully appreciate it.

This just became a great way to leave those who created the actual feature thinking "what's it worth? I get cut out...". This becomes even more serious because brilliant people are usually extra proud of their work. «This feature will probably be able to do what it is supposed to, but also... save the world». It becomes something that breaks the creativity flow and an actual motivation breaker.

But it has to be done. My suggestion is that you take some steps to help people in overcoming this:

• Explain it right from the start. Make it clear that a prototype is not a final product. A product is not only lines of code but involve marketing, design, sales... sometimes even a strategic shift in the organization. Manage the expectations of your team.
• Build some kind of "lab feature set". Have a portfolio of cool features and manage that just as some quick-wins you may have in the product lifecycle. Make them known internally, do some internal market test. You'll be deploying it without actually deploying. Branch the code and you'll be able to go back to it at any point in time and move it from a lab prototype to an actual product feature much more easily.
• Congratulate the one who did it. Do it loud. It is actually a great feature so have no problems in telling her/him that it was actually a great work. You like it! Recognize it!

Hopefully you'll still end up with a high creativity level, a happy developer and one more good item on your feature set.

Feature teams

Feature teams are an absolute booster of usability in an application. They will focus much more on smaller end-to-end requirements, giving the users a better full scope glimpse from the first sprints.

Check this post from Mike Cohn

SQL Server, Google like, full text search

Michael Coles just published a very interesting article on how to build upon SQL Server full text search capabilities by using user friedly (google like) search statements.

Find it here: http://www.sqlservercentral.com/articles/Full-Text+Search+(2008)/64248/