Ivan Sanchez

The Mythical Man-Month is a great book not only because of its insights about software projects. Fred Brooks also writes about the “The Joys of the Craft“:

Why is programming fun? What delights may its practitioner expects as his reward?
The first is the sheer joy of making things. [...]
Second is the pleasure of making things that are useful to other people. [...]
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. [...]
Fourth is the joy of always learning, which springs from the non repeating nature of the task. [...]
Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff.

Really worth the reading.

Work Craftsmanship, Programming

The Pomodoro Techinique has received a lot of attention lately. The reason is simple: it works. It improves focus, removes anxiety because of time and, most of all, help us getting things done.

But the greatest benefit of the technique in my point of view is that it exposes all the interruptions and bad habits we have when doing our jobs. And that’s my reason to believe it should be used as a learning tool instead of a new way of working.

That means using the technique as temporary assistance, not the end solution. Instead of using the tool to avoid the factors that decrease our focus, we use it to make them visible and then find ways to avoid them.

After all, do we really need a timer all the time to do our job efficiently?

Work Craftsmanship, Pomodoro, Productivity

It’s been exactly one week since I came back from Brazil and now it’s time to share some of what happened there. Like I said before, this tour supposed to be a “mini” tour of three days in companies from Florianópolis, city hosting the Agiles2009 conference. Here are some of my findings:

It doesn’t take long to get to know a company

My biggest fear was that the time wouldn’t be enough to really get to see people working, but fortunately I was proven wrong. Even in one of the companies where I didn’t manage to actually code, in couple of hours I had a minimal knowledge to not feel lost at all. At the end I managed to visit three different companies and enjoy all of them in very distinct ways, which was great.

Bureaucratic companies can waste your time

The company I had planned to visit on the last day wanted me to sign a Non-disclosure Agreement before stepping into their doors. And although my contact was keen on the idea of having me there, they couldn’t get the paper on time (or didn’t want, I’m still not sure) and the visit had to get cancelled. Luckily when I got the news I was already in my best friend’s uISV office and working with him turned out to be excellent. In the future I’ll definitely skip bureaucratic environments.

Every company has cool tricks to share

The best aspect of this tour was seeing all the interesting stuff those companies are doing in practice, rather than through papers, blog posts or talks. Although I had no idea of what I would see in those places, it has proven to be a very rich experience. Among the things I’ve learned or played with are:

• Saw a lot of tricks for SEO and how they made a difference for a website
• Participated in a “internal workshop”, where programmers have to talk about a topic they decided to study during the week (in that case, it was about SOLID principles)
• Had a chance to pair program using Pomodoros (I had only tried alone before)
• Saw a way to maintain custom versions of a software and incorporate client’s specific requests
• Wrote my first lines of production code in C#
• Learned more about web scraping
• Realised that the combination of espresso machine and table football in the office can be very addictive!

Smart companies share their problems too

It wouldn’t be polite putting here all the challenges these companies face or practices I don’t particularly agree with but, trust me, they were really inspiring. What impressed me is that, maybe because of the nature of my visit, all the companies had no problem talking about or even showing the problems in their code/process, or even the short cuts they’ve been taking to deliver their software. And hopefully my thoughts on these problems can help them somehow.

I can’t wait to do it again

At this point it’s pretty obvious that I enjoyed the tour and hopefully I’ll be able to repeat it soon. Maybe reserving more time for each company would be better, but even just for a couple of days experiencing a completely different work environment was definitely worthwhile.

Work Craftsmanship, Programming

Most of recent software development approaches bring code closer to business. According to Agile we should write software with customer collaboration, responding to changes and constantly delivering business value. Lean is all about creating a flow of business value and removing waste. Even Domain-Driven Design advocates having an ubiquitous language between programmers and business people.

It’s interesting how most of state-of-art approaches to software development are focusing on business, programming itself is still seen by many as a completely technical discipline. In my point of view it’s time for this to change.

Here are some examples of useful things I believe all programmers should be concerned about these days:

• Understanding the company’s vision and the business model where your software is supposed to fit;
• Knowing how to estimate and prioritise work based on criterion like return of investment (ROI) or competitive advantage;
• Learning about the business domain and becoming an expert in it;
• Questioning the business value of features before start coding;
• Being able to collaborate with whoever is envisioning the solution you’re creating;

All these skills represent a new challenge for programmers, and learning some of them can be more helpful than hacking the last open source framework out there.

The best programmers I’ve been in touch with lately seem to understand that and can explain not only how good their code is but how their organisations are taking advantage of their tricks.

Work Craftsmanship, Programming

The following parable has made me think about the different views on the software development work:

A traveler came across three individuals working with stones. When asked about what he was doing, the first one replied, “I’m a stone cutter. I cut stones because I need the money to support my family“. The traveler then decided to ask the second worker, who answered, “I’m a great stone cutter. I can use all my techniques to produce the best shaped stone“. Surprised by the two distinct responses, the traveler finally asks the third man what he was doing. The worker stopped for a moment and then said, “I’m a stone cutter and I’m building a cathedral” .

Sometimes I have this feeling that we as professionals are frequently trying to be more like the second stone cutter than the the third one. Am I the only one?

Work Craftsmanship

We had some years to digest the Agile Manifesto. Now it seems like the next step is being defined in the Software Craftsmanship Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

We’ve been learning to produce better software for a long time so it seems natural to start asking ourselves to be more responsible about what and how we deliver it.

Work Agile, Craftsmanship

One of the highlights of the Software Craftsmanship Conference 2009 came from outside the original programme. Someone had the excellent idea of proposing the following topic for an open space session: “Why I hate frameworks”. It was enough to get my attention and before I realised the room was so full that people had to sit on the floor to be able to participate.

The discussion obviously started with frameworks for Java. It seems everyone agrees that the enterprise culture of Java introduced a huge amount of tools many developers can’t live without even though their actual benefits are at least questionable. The next question then was whether developers should be so dependent on such tools.

On one side they allow them to think on an higher level of abstraction and follow standards shared by many other professionals. As consequence it becomes easier to find people to work on these projects, specially if the most popular frameworks were chosen.

On the other hand, this approach produces a great number of programmers who only know how to work with those specific tools without even understanding the problems that are actually being solved. Then it becomes harder and harder to evaluate if a framework make people produce more and better.

A point most people agreed is that in some cases frameworks just move the complexity from one place to another, and the productivity at the end doesn’t pay off. And in many cases when people start facing the problems brought by a framework it’s normally at a stage where abandonning it means almost recreating the whole system from scratch.

The fact that many projects are trapped by frameworks brought up the question whether developers should be looking for libraries instead. It seems there’s a lack of libraries because people prefer to develop their solutions integrated to frameworks and then reach a bigger community instead of just solving a problem in isolation and letting programmers mix and match tools to use.

At the end of the session there was no real conclusion on how justifiable is the hate towards framework. Instead, there was a common sentiment that programmers should be more responsible when choosing frameworks. And maybe a clear list of problems they are solving and comparing them with the new challenges they bring may be a good starting point.

Work Craftsmanship, Programming

In an area dominated by acronyms like DRY, YAGNI, FIRST, SMART, KISS or catchy expressions such as Fake It Till You Make It and Baby Steps, a very important practice which is becoming forgotten is Programming By Intention:

This is the practice of pretending that classes, functions, procedures etc. exist (even though they do not) as you structure and write your code. This helps a developer think about the overall process and larger steps of software rather than the small details.

Although it may sound a little weird, the definition above really points to essence of this practice: pretending a piece of code is there to help you focus on the bigger picture. It forces us to think about what we’re trying to achieve instead of going into all the details first. And this small change in priorities makes a huge difference.

As critical thinkers we are always breaking the problem into smaller pieces and trying to put them together like a puzzle. And sometimes we decide to build these pieces one by one in sequence, and not by importance. By adopting this approach we lose great opportunities to learn early about the solution we’re building. We also lose time refactoring and throwing out code when we realise the pieces could be arranged in a simpler or more understandable way.

And that’s where the beauty of Programming By Intention lies: it effectively helps us to make sure we’re solving the problem first, and writing all the support for the solution later. And that’s why I wish there was a buzzword for it too.

Work Agile, Craftsmanship, Programming, TDD

How do you tell if a team is agile? If the last years trying to follow the principles of the manifesto taught me something is that in a good software project people want to be accountable.

We’re knowledge workers. What we deliver is a direct result of the perception of the problems we are exposed to. Yet, there are a lot of people trying to escape from the responsibilities our job requires.

Some of these responsibilities include:

• Design decisions (TDD)
• Impact of our changes on the rest of the project (CI)
• Sharing knowledge and the code where it’s represented (PP/Standards)
• Making sure what is delivered has any value (Reviews/Frequent Releases)

In this context there’s no room for peonage. Our job is basically to make decisions all the time and being agile is about making sure we can answer (and answer well!) for our actions.

That’s why I agree with Patrick Kua’s post about this topic. We have to understand the business problems and the possible solutions. We have to help each other to build something. We can’t stop learning. We can’t  be limited by our normal role. And most important: we have to care.

Work Agile, Coaching, Craftsmanship, Teams

In his talk at the Agile2008, Bob Martin proposed an addition to the Agile Manifesto:

Craftsmanship over Crap.

Although most of us can identify with that statement, it’s probably not easy to sell the idea put that way. But now he rephrased it to:

Craftsmanship over Execution.

I confess the first time a thought about software development being a craft was in a Joel Spolsky’s article disagreeing with the use of this term. In the post he suggests creating software is more related to design than craftsmanship, but he reinforces the idea of software not being simple execution.

After working with a lot of different people, it’s easy to distinguish who think about software as being craftsmanship or mere execution. And undoubtedly the best developers and consequently the best software always come from the first category. They care about what they’re producing, are passionate about it and never stop learning. They want to become master craftsmen and know it depends only on their own attitude.

The question is: should the Agile manifesto include that statement? Personally I don’t believe so. The “Individual and Interaction over processes and tools” part already implies that. Focus more in processes and you’ll end up caring more about execution. Value people and the craftsmanship aspect of building software will become natural.

Work Agile, Craftsmanship, Programming