Distributed Source Control and Set-Based Design

March 10th, 2009 by franktrindade 1 comment »

That distributed version control systems are the current flavour of the moment, everybody already knows, so I’m not here to talk about the N reasons why you should not use svn/cvs anymore.

But what I hadn’t notice until recently is that git (or any other DVCS) actually allow you to do one very important thing in software development: set-based design

As Mary Poppendieck pointed out:

Toyota and 3M use the same concept for product design.  They explore the entire solution space and find intersections that everyone finds acceptable, gradually adding detail and converging on a solution.  This approach is called set-based design, and contrasts sharply with point-based designs which start with a single solution that undergoes a series of optimizations.  In most cases, set-based design produces the best design in the shortest amount of time with the least amount of communication.  It’s strange that this principle, so obvious when you are scheduling meetings, seems counterintuitive in the development environment

The eureka moment came to me in my latest project (in which i’m using svn), when I was thinking about exploring an alternative path to some code that was already implemented, but I thought it could be redone in a better way. How to do it with svn?

I could enter the obscure world of svn branches and merges, where I would have to fight hard to get my code back in one piece, but that didn’t sound inviting at all, and that’s why I haven’t actually implemented the second option, waiting to be more certain about it.

The interesting thing is that since I’ve been using git for the last year, I always took it for granted, and didn’t actually realize this benefit from DVC systems.

So, if you are thinking about why change from cvs/svn to a distributed system, add this point to your list.

1 comment »

Posted in Development, software

Tags:

Does it Really Work?

March 5th, 2009 by franktrindade 4 comments »

Last week during TW London Last Thursday event, I had the pleasure to see this presentation from Dave Robertson and John Johnston (or at least part of it), about how Agile and User Centered design are more a match, sharing goals and values, than different approaches to software development.

If you have some time you should really watch it, it is worth the time.

The overall presentation is really good, but the reason I’m posting here is one specific point that was mentioned, which I believe really hit the spot, and that’s when they say we should rethink the word work in the “the simplest thing that could possibly work” sentence.

This point goes back to the Agile Vs Usability discussion and it is very correct IMO, because it reiterates that development teams should not deliver any code just because it was quick to develop it and the client is happy (although he shouldn’t be at all) since it didn’t cost a fortune.

And what is interesting about this subject is how agile teams don’t usually accept low quality code standards (code without tests, lots of hacks, etc..), but easily accept low usability standards, not understanding that is also their responsibility to define what a good user experience is.

What I’m NOT trying to say is that the user should be left outside from the application design. He should definitely have his opinion (and a strong one), but should also receive advice in UX standards as much as he should in code quality, making sure that he understands what he loses when is trying to save money on each particular feature.

4 comments »

Posted in Agile, Development, Management, software

Tags:

T-Shaped People vs Generalists

March 3rd, 2009 by franktrindade 2 comments »

I’ve been reading Mary and Tom Poppendieck’s new book on Lean Software Development, and in one of the already released chapters, it mentioned the term T-Shaped people, which I had never heard in this context, and suddenly clarified a concept I have in my head for some time.

Since Scott Ambler published the essay Generalizing Specialists, it has become a trend in software development to talk about how generalists are better than specialists for a team, which (in a misinterpretation of what Scott meant) has leaded to a common anti-pattern, where persons become generalists in a lot of stuff, without having a deeper knowledge in any any area.

This way they know a little about a lot of languages, tools  and methodologies, but when it comes to make a difference, these persons are no assets to any team, since they don’t have any deep knowledge on any subject.

This was already covered by Jay Fields in this post, and what I want to point here is how the T-shaped term makes so much difference.
According to IDEO’s Tim Brown, in the  the article is called “Strategy By Design”, here is how a T-shaped person could be described:

“We look for people who are so inquisitive about the world that they’re willing to try to do what you do. We call them “T-shaped people.” They have a principal skill that describes the vertical leg of the T — they’re mechanical engineers or industrial designers. But they are so empathetic that they can branch out into other skills, such as anthropology, and do them as well. They are able to explore insights from many different perspectives and recognize patterns of behavior that point to a universal human need. That’s what you’re after at this point — patterns that yield ideas.”

And that’s what happens in software development. Once you have a deep knowledge in some language, for example, it is easy to branch out to different ones, since you can recognize the same (technical and behavioral) patterns, which will lead you to soon become competent in that area too.

But this situation does not happen if you always stay at the novice level, without never mastering anything you do.

2 comments »

Posted in Learning, Management, software

Tags:

Rails 2.3 New Features

February 2nd, 2009 by franktrindade No comments »

In the set of new features from Rails 2.3, I was quite pleased by two of them: nested attributes and nested forms.

Both allow the creation of forms containing information about more than just one model, and may solve a recurrent problem I had in past projects, which has lead to some painful headaches…

Can’t wait to try it!

More information (source):

3.1. Nested Attributes

Active Record can now update the attributes on nested models directly, provided you tell it to do so:

class Book < ActiveRecord::Base
  has_one :author
  has_many :pages

  accepts_nested_attributes_for :author, :pages
end

5.1. Nested Object Forms

Provided the parent model accepts nested attributes for the child objects (as discussed in the Active Record section), you can create nested forms using form_for and field_for. These forms can be nested arbitrarily deep, allowing you to edit complex object hierarchies on a single view without excessive code. For example, given this model:

class Customer < ActiveRecord::Base
  has_many :orders

  accepts_nested_attributes_for :orders, :allow_destroy => true
end

You can write this view in Rails 2.3:

<% form_for @customer do |customer_form| %>
  <div>
    <%= customer_form.label :name, 'Customer Name:' %>
    <%= customer_form.text_field :name %>
  </div>

  <!-- Here we call fields_for on the customer_form
       builder instance. The block is called for each
       member of the orders collection. -->
  <% customer_form.fields_for :orders do |order_form| %>
      <p>
        <div>
          <%= order_form.label :number, 'Order Number:' %>
          <%= order_form.text_field :number %>
        </div>

  <!-- The allow_destroy option in the model
       enables deletion of child records. -->
        <% unless order_form.object.new_record? %>
          <div>
            <%= order_form.label :_delete, 'Remove:' %>
            <%= order_form.check_box :_delete %>
          </div>
        <% end %>
      </p>
    <% end %>
  <% end %>

  <%= customer_form.submit %>
<% end %>

No comments »

Posted in Development, Rails

Tags:

The Forces of Destruction

January 21st, 2009 by franktrindade 5 comments »

This post came to my mind while reading this post in Sarah‘s blog .It is not my intention to discuss pair programming (or flying a plane) here, but one thing that got my attention was the mention that there is a culture bias towards single programming, more specifically:

…Gladwell has lead me to start believing that there is a cultural bias towards single programming. Take universities for example – you can be expelled for working collaboratively; individual results count, team work in assignments is often discouraged.

And I definitely agree with it. Actually, that is exactly what Deming says in one of his books. According to him, everyone is born with a power of intrinsic motivation, dignity, cooperation, curiosity and joy in learning, but all these characteristics are consumed by the “forces of destruction” that our present style of rewards brings with it, like grades in school, competition between people and payment for individual performance.

And if we analyze it, that is kind of the funny part (not to say sad…): We teach everyone since primary school how not to collaborate with anyone. Students cannot share their knowledge in exams, are always competing for better grades, and when these same persons start they work life, one of the most requested skills is what? working with teams…

But like this isn’t enough, the same companies that hire employees “who can work in teams” still have individual performance reviews, blame cultures, give individual bonuses and promote managers because of the good performances of his subordinates. And when cooperation is not easy, everyone still wonders why is so difficult for people to work collaboratively.

And coming back to the world of agile software development, this doesn’t stop being a reality. It is not unusual to see teams where only the most experienced people are valued, where project managers have an authority position against the rest of the team and less experienced developers don’t have a say when discussing with more experience ones (and here comes pair programming….)

So, if you really want your team to work collaboratively, think about all the times where you are measuring and rewarding them individually, and stop doing it!

5 comments »

Posted in Agile, Development, Lean, Management

Tags:

The Wire Mistery Solved!

January 10th, 2009 by franktrindade No comments »

As a huge fan of  the “The Wire” series, as I always wondering how the Baltimore police  and its homicide department could be so bad. How could they have so many problems when trying to solve the crimes in the city?

Guess what, when watching one episode of the 5th season, I finally realized the source from all their problems, as the next picture shows…

bunk

They use Lotus Notes!

After that, is no wonder that the crime rate is so high….

No comments »

Posted in Uncategorized

Tags:

Speaking About Agile 2008

January 9th, 2009 by franktrindade No comments »

For the portuguese speaking crowd, the video from the presentation me and Danilo did last year at Falando em Agile 2008 is now available.

If anyone is interested, the slides can be downloaded at the presentations tab of this site.

No comments »

Posted in Agile, Presentations

Tags:

I Love Banks

December 11th, 2008 by franktrindade 3 comments »

Deviating a little bit from the agile topics, Im writing this post to tell a little story about my relationship with a certain british bank, and how well they use IT for the client’s benefit.

I dont want to tell the bank’s name, because the purpose is not to create bad advertising or something like that, so for the moment I will just call this institution the bank of the citi.

So, beginning the story, last month I was surprised by having been charged interests in my credit card bill, despite having the feeling that I had payed in the right day. I sent my bank a message, which was replied:

our payment due date was 27th October 2008 and your payment was made on the 29th October 2008. Because the payment was late you have been charged the late fee and the interest.

Ok, but I still thought I’d payed in the right day, so I checked my account info and verified it. Second message to the bank of the citi:

my account info show the transaction was made on the 27th.

27/10 TRANSFER 538813

Why it is just considered in the 29th?

And then comes the surprise (in form of a reply):

When making a debit card payment to your credit card the timescales are up to two working days for it to clear onto your account.
If you require anything else please don’t hesitate to contact me again.

Then I thought: What?? And kept trying to understand how possibly it could take 2 working days to transfer some money electronically to the same bank.

Since I was in a good mood and the attendant had offered me his help, I decided to send another message:

I think the only question I have is how come it takes 2 days to do an electronic transfer, but probably it won’t solve my problem.

And here comes the answer:

It takes two working days for a debit card payment to clear onto accounts as it has to go through clearing and then be allocated to the correct account.

Oh, now I understand… It’s not a simple operation, like transfer the money. You actually have to subtract the money from one account, clear it (whatever this means), and then transfer it to the other one.

For some days after this whole conversation occurred, I tried to think how someone managed to build some software that needs 2 working days to perform one operation.

I thought that maybe there’s one batch job that gets the money from my account (which runs at midnight at D+1) and another one that gets this money and adds it to the other account (midnight at D+2), or  both operations happen at D+1, but then they need 24 hours to verify if the transaction was correctly performed, or there’s actually a person that goes to the safe where my account is, counts the money, and then goes to some other building where the bank account is, opens the safe and stores the money there… actually, no, this would be much faster than 2 days.

3 comments »

Posted in Uncategorized

Focus on the Right Point

December 8th, 2008 by franktrindade 2 comments »

This post came from a pub discussion with Liz, and actually originated from this thought I’ve been having for some time, an came back in one of my recent readings (not to say also in one of my recent projects)…

I participate in some agile mailing lists, and one question that frequently happens is what I should do about people not showing up/showing up late for the stand-ups in the morning. And normally this comes with statements like: “I’ve tried it all already: waiting, not waiting, punishing late arrivers, making them buy ice cream, etc… and nothing works”

And this situation came again to me mind while reading Ricardo Semler‘s book, Voce Esta Louco! (not published in english so far, but it means You Are Crazy!), when he describes how flexible time was introduced in his company.

To give some context, Ricardo runs Semco, a brazilian company which has business units in a lot of different areas, from shipbuilding to hotel management, but is best known for the industrial democracy that its owner has been implementing since the 80′s.

This particular situation he describes occurred when Semco, in the 80′s, was going to allow production line employees to have flexible work hours, and as expected, most of the top managers were totally against the idea, since it violated a basic principle: for a production line to work, everybody has to be there at the same time.

And ricardo’s answer for that was (free translation):

It’s obvious: if the employees are not working at the same time, the production line stops. We know it, but the adults that work in the production line also know it. And why would they put their productivity and their jobs at risk? If they are not worried about how the production line is, producing or not, then we have a much bigger problem, and the sooner we know it, the better.

And that’s what happened, one day before the program started, the employees gathered and decided what time they would start to work.

But what does this have to do with daily standups? Well, the whole example was to indtroduce the same answer I always give to these questions: if your team doesn’t show up for the standups, you shouldn’t worry about why they are late, but ask yourself why they don’t care. That’s your problem.

2 comments »

Posted in Agile, Development, Lean, Management

Tags:

Agile vs. Usability?

November 25th, 2008 by franktrindade 7 comments »

Thre’s been a recent discussion around how agile methods face usability, mainly following Jakob Nielsen’s post about how agile, if poorly executed (that’s my opinion), can be a threat to usable software.

I don’t want to say again what was already said, and I believe that agile and usability can be a good match, as long as you know what you’re doing, but what sometimes bothers me is the common thinking around agile methodologies, that usability = what the client wants. I’ll explain.

In most of the agile projects I’ve been (not to say all of them : ) ), whenever there is some issue around how to make some feature in terms of usability, like “how should be the user experience around this operation”, the common answer is: “let’s ask the client..”.

Well guess what? The client never thought about usability in his life. Of course he used computers already, but he probably doesn’t know how to better develop an application to make it more usable. And this situation gets even worst when the client is just a proxy to the real user, who will probably not even work in the application being developed.

To give a pratical example,  if you asked a bunch of people how they would like to search for web pages in the pre-Google era, how many do you think would answer a “blank page with a text field on it”?

If this ask-the-client behaviour comes from pure lazyness or some cover-your-behind strategy, that’s another discussion, but what I think most agile teams should change in the way they work is to stop pretending that the client has all the answers, and trust a little bit more in themselves to create solutions.

And my guess is that the clients would also like it, because I don’t believe they want to spend their time answering questions like “which is the best solution for this problem: a select field or radio buttons?”.

And if you really want to trust the client to tell you how to build software, do it in a real HCI fashion, observing real users using your application and getting your answers from there.

Cheers,

Francisco.

7 comments »

Posted in Agile, Development

Tags: