Hexacta Blog

Software Engineering versus Software Management

Santiago Ceria — Wed, 28 Jul 2010 16:33:16 +0000

Before getting into discussions about SEMAT I need to talk about a related topic I think will clarify my point of view on the initiative.
In Nov 1990 Mary Shaw published in IEEE Software a great, very influential paper titled “Prospects for an Engineering Discipline of Software”. In November 2009 she published an update of her view on the subject titled “Continuing Prospects for an Engineering Discipline of Software”. This short article is also very interesting and I would like to extract a paragraph from it. Talking about CMM, Shaw says: “Software has engineering challenges aplenty, and mislabeling management and process issues as “engineering” diverts attention from the equally important technical issues of creating a systematic, scientific basis for an engineering discipline. Our prospects would be better if we’d recognize the former as “software management,” allowing the latter to fully occupy the mindspace of “software engineering.” No other engineering discipline suffers this confusion. As for our field’s maturity, whenever someone says, “We don’t need technical advances; we need a better process,” that’s a sign that production skills haven’t yet brought us to a fully mature commercial practice.”
Commercial practice, according to Shaw, is the previous step to Engineering Discipline, where we have a strong and widely accepted scientific basis. I think that Shaw is right in that equaling software process issues to software engineering is wrong and misleading. And that mistake is one of the reasons why some people, who are also wrong in my humble opinion, say that “the whole engineering approach to developing software is wrong”. If you are to believe in the SEMAT initiative, you have to agree on the definitions that Shaw presents on those two papers. In an MIT course I found a definition of engineering that is very simple: “Engineering is purposeful science”.
As I do agree with Shaw’s definitions, I think the SEMAT initiative is headed in the right direction. More to come…

SEMAT – A new hope?

Santiago Ceria — Mon, 19 Jul 2010 23:01:38 +0000

During the SEAFOOD conference I attended in June we had a Keynote from Ivar Jacobson where he presented the SEMAT initiative that he is leading with Bertrand Meyer and Richard Soley. I have to include some texts to present SEMAT:
“Semat seeks to develop a rigorous, theoretically sound basis for software engineering practice, and its wide adoption by industry and academia.”
The SEMAT Call for Action states:
“Software engineering is gravely hampered today by immature practices. Specific problems include:
• The prevalence of fads more typical of fashion industry than of an engineering discipline.
• The lack of a sound, widely accepted theoretical basis.
• The huge number of methods and method variants, with differences little understood and artificially magnified.
• The lack of credible experimental evaluation and validation.
• The split between industry practice and academic research.
We support a process to refound software engineering based on a solid theory, proven principles and best practices that:
• Include a kernel of widely-agreed elements, extensible for specific uses
• Addresses both technology and people issues
• Are supported by industry, academia, researchers and users
• Support extension in the face of changing requirements and technology”
It’s hard not to agree with the above. However, some important persons in the international software engineering community such as Alistair Cockburn believe that this initiative is flawed (see: http://alistair.cockburn.us/A+Detailed+Critique+of+the+SEMAT+Initiative). For the moment I invite the readers of this blog to take a look at the SEMAT site. I’ll come back soon with my comments. Initially, I find this initiative very promising and I believe that the fact that the goal they are trying to achieve is extremely hard shouldn’t prevent us from giving it a try.

SEAFOOD Presentation

Santiago Ceria — Tue, 13 Jul 2010 19:21:55 +0000

Last month I presented at SEAFOOD 2010 a paper we wrote with Carlos Pallotti about Argentina’s Offshore Software Industry. It’s great to see how Argentina is, little by little, getting more attention in the offshore landscape. However, we are not alone: many countries around the globe are doing the same and many of them have interesting competitive advantages. Just to mention an example, Russia, the Country that hosted the conference, has a very compatible time zone with Western Europe and a very strong scientific system. I also got the impression that Argentina is somewhat ahead in the adoption of innovative Software Engineering approaches. I hope this will also help us.

I got an interesting question from someone in the audience who asked “Considering Spanish is the most spoken language in the world after Mandarin Chinese, why do you say that Argentina’s good level of English is a competitive advantage”. My answer was the typical “The most attractive markets require English”, but it left me thinking whether Argentina is using this opportunity as much as it should.

We also had quite interesting Keynotes from Ivar Jacobson, about SEMAT, from Bertrand Meyer, about Empirical Software Engineering, and from Richar Soley, about his work at OMG. The SEMAT initiative is very interesting, although it received some powerful critics. I’ll write a post about it soon.

Innovation in Offshore Relationships

Juan Navarro — Mon, 05 Jul 2010 18:32:20 +0000

The other day I ran into a very interesting McKinsey article. It describes how successful innovators are shaping the offshore industry. I found the article very clear and right on the mark. It is titled “How innovators are changing IT offshoring”, available from the McKinsey Quarterly. If you have access to it, I’d recommend you read it.

Basically, the authors argue that to achieve long term productivity in an offshore relationship, clients and vendors should engage through a “managed service” model instead of the more traditional “staff augmentation” model. The “managed service” model implies that more leeway is granted to the vendor, so as to allow the offshore company to staff and manage the team more freely. The client does not micromanage what’s happening in the offshore location. In turn, more responsibility for the delivery of concrete services is demanded from the vendor, as well as deeper functional knowledge and alignment with high level business metrics of the client. This model requires trust. Trust is hard to come by these days, but it’s very powerful when appropriately leveraged in an offshore relationship.

Most interesting is one of the metrics brought to the table as an indicator of successful relationships: people retention.

At Hexacta we have always believed that keeping a motivated team is crucial to achieving high productivity and to retain valuable resources. Key for keeping motivation high is setting up the right team structure in the offshore location. Offshore teams should be structured with different seniority levels, and should have a strong local management. Having different seniority levels in the team allows for the most complex tasks to be tackled by the most experienced developers while the easier and repetitive tasks are tackled by the more junior team members. This provides room for people to grow, to coach and to be coached, thus rising motivation. Team member rotation is also necessary. When appropriately planned, functional knowledge is not lost, it is refreshing for the team and ends up generating a much higher retention level.

It is nice to hear that what we’ve advocated for many years is now recognized as a best practice. It’s also nice to be called an “innovator” after so many years of thinking the same way!

Latam vs. India

Ricardo Farias — Thu, 27 May 2010 14:14:16 +0000

A few weeks ago I attended the webinar “Near-shoring in Latina America” organized by ThinkSolutions and the Outsourcing Institute. Although this webinar was targeted to US companies seeking to offshore, it was very interesting to participate as a services provider.

I was surprised, and so were the organizers, about the large number of people attending the event –a proof of how Latam is stepping forward to a major role in the global outsourcing industry. The webinar´s themes were about the outsourcing differences between Latam and India and what are the strengths of the region.

Here is a summary of the main points discussed that are worth mentioning:

First, as India is experiencing the new IT “gold-rush”, its average service price is rising. Second, English is taught as a second language in Latin-America. Third, the region is closer than India to the US market. Finally, Latam has lower turnover than India and it has a closer cultural affinity with the US.

These last two stand out as they represent the greater pain-points for an IT manager looking to offshore. The lower turnover means a more stable team for a smoother and timelier project; in fact Latam has 5% less turnover than India. Latam´s cultural affinity with the US plays a key role in the communication process between the two parties, lowering the risk of unwanted surprises. Moreover, Latam culture replaces the Indian “Yes to everything” to the “straight answers one.”

Some of the other advantages of outsourcing to Latam discussed in the webinar are: good telecommunications infrastructure, high quality education system, similar time-zone with the US, presence of the leading technology providers like IBM and Microsoft, well trained developers and managers, who already have experience in important projects and finally the rising support of the local governments.

To sum up, many people in the US and other markets seem to be recognizing that Latam has unique competitive advantages, quality resources and the technical capability to seduce US business to work with local companies. The industry is growing fast, and there is no doubt about the arrival of the region as a major player in the global outsourcing scene.

Is decision making a key skill for software engineers?

Santiago Ceria — Fri, 16 Apr 2010 19:12:25 +0000

A few weeks ago I attended the 23rd annual software engineering education and training conference in Pittsburgh. One of the keynotes was given by Alistair Cockburn, one of the authors of the Agile Manifesto. His lecture was titled “Teaching the next generation software engineering”, and the slides he used can be found here: http://alistair.cockburn.us/Teaching+the+next+generation+software+engineering.pps. In his lecture, Mr. Cockburn explained that people can learn skills in three stages, following a Japanese martial arts concept: Shu – Learn one technique, Ha – collect techniques, and Ri – Invent / Blend techniques. Mary Shaw, who always has good questions that are hard to answer, was in the audience and seemed very interested in the subject. This time her hard question was: “How do you teach students how to choose between different techniques?”

I often say that the best software engineer is the one who knows many different tools, techniques, methods, and has the skills and judgment to choose among them. Now… the question is: how do you do that? This is like going to a restaurant. On a plane, the dinner decision “chicken or pasta” only takes a few seconds. In some Argentine restaurants the menus are up to 10 pages long, and it takes forever to make up your mind. Of course there are several standard decision making techniques that we can use as software engineers. But I’ve never seen that as a focus of our education or the skills that we need in our job. Maybe it’s time to review that. Also, we might need specialized decision making techniques. For example, the SEI has done a nice job by linking quality attributes to architectural decisions. We need more of that for other key decisions we have to make when we develop software, both for managerial and technical issues.

On the cruelty of trying to be a software engineer

Santiago Ceria — Thu, 08 Apr 2010 17:45:22 +0000

Last month I had the chance to go back to Carnegie Mellon, the place where I studied 17 years ago. It was a great experience to see how the place has changed and to meet again good old friends. I was given the chance to give an alum presentation that I decided to title “On the cruelty of really applying what you learn in the MSE (Masters of Software Engineering)”. The title was inspired on Dijkstra’s manuscript “On the cruelty of really teaching computer science”, which is very, very interesting, because it describes how sometimes we fail to recognize some things that are radical novelties as such. The problem in these cases, according to Dijkstra, is that we try to link the radical novelty to what we already know, the new to the old, and, according to him, these attempts are doomed, because what we know is “hopelessly inadequate”. I used this title because applying what I learned in that program is also cruel in some ways. First, because what you learn there is fundamental, so some things can’t be applied directly, second, because some things are novel, so they can’t be applied immediately, and third, because our field is too wide, so some things might not be useful to all students.
But there’s also the cruelty of trying to be a software engineer. Many say that software development is not an engineering discipline because it’s not mature enough. Dijkstra used to say that it’s a doomed discipline because it’s an attempt to apply something familiar (engineering) to a radical novelty. Others say that developing software is more an art than an engineering discipline. And traditional engineers, when you explain them that physics and chemistry are of little relevance for developing software say “if it doesn’t require physics or chemistry, then it’s not engineering”.
But let me get to Dijkstra’s argument, which is very interesting. How many times did we make mistakes in the past by trying to apply practices from other engineering disciplines that were not adequate for software? Is that the case of many things we tried to copy from manufacturing? Is that the root cause of the “waterfall mentality” that still persists in many places? I think that saying “All previous engineering knowledge is useless for developing software” is clearly wrong. But we should also be more careful when we try to use things from other disciplines. And this applies not only to people like me that want to inspire in traditional engineering, but also to people that claim that software is an art (I’m talking here about developing large software systems, not the “art of programming” that Knuth described so well).

Some of the problems I see in Agile Methods – Part 3

Santiago Ceria — Fri, 11 Dec 2009 20:19:09 +0000

A few days ago I was talking to a colleague and he told me “I’ve convinced my boss to start using Scrum”. “Great!”, I replied. But then he started to describe his situation and the problems he is having. And the main problem was that they still didn’t have a product backlog. And his question was “What do I do before I’m ready to do my first sprint?”. This is not exactly the issue I would like to discuss, but it reminded me of another problem I see in agile methods, and it’s the idea that “all sprints are equal”.

Let’s analyze some differences between two iterative and incremental processes: Scrum and UP (or RUP). One significant difference is that UP has the notion of Iteration Phase, or Iteration Type. This means that not all iterations are equal. And this makes a lot of sense to me. Not all iterations are equal because when you start a software project there are many unknowns and things you have to analyze and think about. And when you are about to deploy a system to a production environment or release it to customers there are many other things you need to do that are different from what you do during construction. This doesn’t happen all the time, but it happens often. And then you start seeing agile teams that do “Stabilization Sprints”, or “Release Sprints”. I’m sure those are forbidden words for many agilists, but at least I was relieved to read a post by Mike Cohn about release sprints where he describes a Bank that manages a 13 million LOC core system that needs them. Believe me, they are not alone.

I think Agile methods should put more focus in these issues, which are very relevant in many projects. And give practical and specific advice on how to do all this while being agile. In other words, I don’t think minimizing the potential differences in sprints is a good idea.

So, in this case, the problem I see in Agile methods is not related to what they say, it’s to what they don’t say.

Google DevFest 09

HAT — Wed, 25 Nov 2009 15:12:38 +0000

17th of November was a very cool day, i could enjoy the Google DevFest 2009 in Argentina and i will share you some exiting thinks from this event.

Some news about Google Apps

Google is working in a lot of new stuff, one of them is the improvement of the GEO API. The 3th version of Javascript API for Google Maps is growing up faster and its focused on speed browsing and will bring us some new cool feautres.

Android is hitting the 2.0 version and this week Motorola is bringing to the market a new cellphone with this operative system.

Others topics they talked about are Google App Engine, Google Wave, Open Social, Google Chrome Extensions and HTML 5.

DevFest09 documents

Some of the problems I see in Agile Methods – Part 2

Santiago Ceria — Sun, 22 Nov 2009 13:16:51 +0000

Another problem I see in some Agile Methods is a lack of flexibility about the rules they propose. I see that as some kind of contradiction: for example, Scrum is empirical only for things that it does not define beforehand.

“Don’t change Scrum” is something that Ken Schwaber wrote in his book Scrum and the Enterprise. Here’s his rationale for this: “Scrum isn’t a process that you can modify to fit your enterprise. Instead, it exposes every dysfunction in your enterprise while you build products… Whenever people change Scrum, it’s because they’ve run into a problem, dysfunction, or conflict that they do not want to face and fix. Instead, they change Scrum so that the problem remains invisible and remains deadly to the enterprise. If you allow this to happen, you will have lost Scrum’s primary benefit”.

I know that I can’t change the speed of light… But… why can’t I change Scrum? And what exactly is it that I can’t change? Are Scrum advocates so sure that it doesn’t make sense to have standups twice a day or once every two days or that they can last less or more time? Or that I can’t use any other estimation method? Or that being a Scrum Master is a full time job? Or that always the team has to be self organized? Or that scheduling tasks is not needed?

The rationale I imagine for this position is that being flexible will lead to misuses and ineffective processes. And that makes a lot of sense. In the past, for example, this is what happened to CMM and its original appraisal method “Software Process Assessments”. If you’re flexible, as that method was, people that don’t deserve a CMM Level will get it. So let’s make the evaluation method more rigid. And they created CBA-IPIs. But that method was also too flexible, and so they created SCAMPIs. But from what I see, this increasing rigidness is causing more problems than solutions to CMMI.

So what I understand is that some agilists say “If you’re flexible with Scrum, some people will say they use Scrum when they don’t and they will spoil its good name, so, don’t change it”. I really can’t agree with this. Scrum has very few rules, but I see no rules there that can’t be changed if it’s done with expert judgment and based on empirical evidence.