Tag Archives: software

How do you create successful software development teams? (Part 1)

By David Bicknell

Campaign4Change recently took part in a software development roundtable organised by the Dutch software specialist Software Improvement Group (SIG) to find what makes successful teams in software development.

The roundtable featured two specialists in creating specialist teams: Andrew de la Haye, chief operating officer, at RIPE Network Co-ordination Centre (RIPE NCC), one of five Regional Internet Registries (RIRs) providing Internet resource allocations, registration services and coordination activities that support the operation of the Internet globally; and author and management expert Kevan Hall, chief executive of Global Integration.

The event discussed the process in the creation of excellent teams in software development, the qualities shared by successful teams, the role that management plays in their creation, while highighting some of the factors that help create productive teams, and the issues faced by the people managing them. 

Teamwork

Arguably, great development teams typically demonstrate a lot of very tight teamwork, with small groups that all know and understand each other working intensively together.

According to Andrew de la Haye, what makes effective teams  is a mix of  strategy, team dynamics, communication, and multifunctional commitment.

“Clarity on the company’s strategy is extremely important in creating an effective team. Very high level strrategies are very difficult to comprehend in regards to the work. Communication is very important: it is the alignment between what we say and what we do. We have to reinforce and embody the goals we have,” says de la Haye.

“Where I used to work, people might say ‘We were going to the factory today. And that meant the developers sitting in a big room. But the word factory is a bit misleading. These guys are not blue-collar workers. They are highly educated and they are much more intelligent than I am. They are intelligent individuals with lots of ideas, which I want to nourish.

Agile Empowerment

“With communication in mind, what we are also doing is lots of measurement and making it very visible,” says de la Haye. “For example in our room, I have a chart showing the quality of our software  to the team, showing how they’re doing. That contributes to the notion of quality and effectiveness in the team.

“Then there are the dynamics of the group. We use Agile development, which means that we deliver every second week to the business side. The business side may say, ‘We don’t like the feature. We don’t like the colour.’ I don’t care what they say as long as what we produce fits their needs. And because the iterations are very short, it’s very easy to change it.

“Another key factor is empowerment of the team with Scrum. We have a huge board with sticky notes and colours. It might say that a particular feature is required, at a very high level. And then they decide who’s doing what. I’m not even part of that discussion. These guys are very bright and know what they’re good at. I do have some control mechanisms in place. We measure quality and I measure the amount of what they deliver. I don’t ask my developers, ‘Can you tell me how many hours you were working?’ because they are not very good at predicting the amount of hours. But what they are very good at is predicting the complexity based on complexity points. And the complexity points tell me how much time something will take.

“I had this phrase, ‘Quality is cheap,’ and I had some arguments with people over its meaning. What is says that ‘If you do really really good work, the rework that you have to do, which is really more than doing it properly in the first instance, you will be able to reduce that rework.’ And that has to be reinforced. If we hire people, we hire people who like quality and are quality driven and that’s very important as well.

Commitment to quality

“We have multidisciplinary teams. And we have expertise areas, but we don’t have experts. An expert is someone you put on a pedestal and nurture. Someone with an expertise area is willing to broaden that knowledge but also is able to pick up other knowledge. In the Scrum team, we have developers and senior developers. That’s it – no architects, senior architects, enterprise architects. And a healthy turnover is very important as well. For us, it’s about 10-15%. You need new blood in your team once in a while. We are not consultants, so we are not doing cutting edge stuff. But we’re not lagging behind either. So you need to replenish your team with the knowledge that’s available, and that’s very important to the team.

“The final area is the commitment. If you have all these areas well in place, you have a team that is very committed. Committed to quality; committed to our overall goals as a company. They all understand why our company is there. And it’s not to make money. They are empowered and result-oriented. And one of the things that gets me lots of credit is that I give them lots of learning opportunities. We have a budget for our developers  and what we used to do was send them away to the US, to California to a conference, that kind of stuff. And the value that came back was not that much. They may have had a great time, but that’s not the commitment I’m looking for.

“So now I say, ‘Take two weeks in the office. Come in whenever you like. Leave whenever you like and do something you think is interesting for yourself. And after those two weeks, show the team what you have been doing. Hopefully it’s innovative and hopefully people learn from it. It’s not something we need to apply. We might; we might not. But it should be a learning experience for you.’

“At RIPE NCC, we’re not top heavy on mobile applications. And it’s not an area that we need to go into. But we had this guy whose ambition is to work for a mobile operator in a couple of years’ time. And so he created a mobile app for us. I’m not scared of losing him because I expect that turnover anyway. The guy is very committed to his job because I take him very seriously. I help him get to the next level. So he might stay for the next six months and if I really need him he will come back. It’s all about collaboration with my teams.

“My strategy director said ‘I keep going to these strategy conferences and I’ll see the same people the same time over and over again. And they tell me stuff that I already know about because of publications etc, and there’s not much value.’ So then he went to a conference for surgeons which he admitted was way beyond his league. And he said it was so interesting to see this different world, that he actually took away more from a conference with surgeons than those strategy meetings he went to for years and years. And that gave me the idea of just letting these people do what they want to do. It’s not a done deal that they have to spend their two weeks in-house. But most of them do. It’s not that we don’t send them to conferences. I might send them anyway.

“There is a correlation between value delivered and the commitment to what they do and feeling part of what they deliver in Agile development. They have these regular check-ups with the busines and it’s very nice if you build something for two weeks and ou present it to a business person and they are sitting there with a big smile on their face, because he has exactly what he wanted and he never had that before. There is a correlation between happiness, commitment and Agile development.”

SIG pointed that three of its clients which all delivered four or five star software quality had followed a Scrum-like approach or had adopted Agile principles. Scrum teams tend to be more cohesive because they are empowered: they have to do it themselves. They decide amongst themselves what to do to deliver the right product.

Remote working or co-location

In contrast to other IT working environments, there is little or no remote working in RIPE NCC’s software development, says Haye.

“We have everyone here in one environment, which helps create some trust, and understand who in the team does what. Then once they understood each other, then perhaps there’s some leeway for remote working.But first they had to establish the trust.”

“I think it depends what type of work you do,” says Kevan Hall. “I’m a big corporate person.  The only area where I see the big global multinationals moving back to co-location is in very intensive R&D groups, such as the auto industry, because they seem to be unable to manage distributed R&D. One of the big challenges in distributed research teams is serendipity. It’s the bouncing off and the ideas and those kinds of things.  You can do that when you get people together and you can to a certain extent do it through a conference call, and videoconferencing and WebEx and things like that.

“But even in an open-plan office, if you look at how far apart people’s desks are, that affects how often they just spontaneously talk. Anything up to ten metres, you talk. Anything beyond ten metres, forget it.”

Too much teamwork

“It may be shocking, but I actually spend quite a bit of my time trying to discourage teamwork, because one of the things in the kind of organisation that is distributed or  global is that teamwork is really expensive.  It requires people to be accessible in the same time, if not the same place. and for global teams, there isn’t a right time to do that. It’s also very expensive.

“So when the cost of something goes up, the demand for it should come down. But because we’ve got this almost unthinking attachment to teams for everything, it hasn’t. And when we ask people how they’re spending their time, they tell us they’re spending two days a week in meetings, and they get 60 emails a day, 85% of which is irrelevant. We’re just sharing too much stuff.

“I used to be in manufacturing and if somebody told me we were producing 50% scrap, we’d have had a really sharp discussion about the future of that factory.  But we routinely accept 50% waste in collaboration. We have to be much more selective about when we use teams.”

How a Dutch SME is helping make software energy efficient

By David Bicknell

It may take a little time, but in the future organisations will be able to track the energy efficiency of their software and know how much it is costing them to run.

It follows an idea developed by a Dutch SME that specialises in the quality of software. Amsterdam-based Software Improvement Group (SIG) has partnered with the nearby Hogeschool van Amsterdam (Amsterdam University of Applied Sciences)  to create the Software Energy Footprint Lab (SEFLab).

SEFLab is now setting out to establish how the quality of organisations’ software code affects their energy consumption. The work will couple SIG’s knowledge and expertise in software monitoring  with the enthusiasm and technical expertise of the local university students.

Campaign4Change asked Dr Joost Visser, SIG’s Head of Research how it is going about tackling the energy efficiency of software, and what elements of the problem it needs to examine.

Joost Visser: There are basically two types of this problem that you can break this down and look into. One is across the software lifecycle. So just as with software defects where the later you find them the more expensive they are, so with energy efficiency, if you try to optimise your software once it’s already in production, you may have to make an explicit investment that might not provide an adequate payback. But if you already know what requirements you need to keep in mind at the design stage for energy efficiency, then, for example, you might actually choose a different communication protocol which can improve your efficiency. At each of the development process, there are things to do: in requirements, in the coding and in the testing.

Another issue is the hierarchical level of software. The thing you might see as the consumer is the application. But actually that’s not the first level that impacts energy efficiency. The first level is the user themselves. In a car, the person that is actually touching the accelerator has a lot of influence on how much fuel you would use. To reduce your fuel usage, you may need to change your (driving) behaviour. The same thing applies with users of software. If they know what the consequences are of clicking here and searching there, they might behave slightly differently and it might have an impact on energy efficiency. If you give people feedback, they will behave differently.

C4C: What sort of user feedback have you had?

JV: We did a survey around 9 months ago where we asked a lot of users about these types of things and the overwhelming conclusion of that survey was that, ‘Yes, we would like to change our behaviour but at the moment we have nothing to go on. We don’t know how to make that change.’

There is a premium on green products. People want to be green – but they have to be able to make a meaningful choice. There are various elements to consider. First there is the application layer. Then we have the various components from which the software application is built: a database; a runtime environment framework, and Java as a virtual machine. Then underneath there’s the operating system. Microsoft has made a big effort in its operating system to take energy efficiency into account but I think there are many more steps to be made there. Then there is communication. You have to think about your mobile device uses radio to communicate when you’re browsing. You may have to make an explicit switch to a Wi-Fi network which might be more energy efficient. Is it more energy efficient than 3G? We don’t know yet. That is one of the things we’re going to find out.

C4C: One of the areas that many organisations are talking about is the impact of consumerisation and the use of touch devices creating a new user interface that organisations’ applications will have to be rewritten for. What does than mean from an energy efficiency perspective?

JV: One of the very very real challenges now is that we want to go to those new devices with mobile strategies but time to market dictates how we think about energy efficiency. So you might choose to do develop once on different devices but on many devices, there’s no accounting for the energy consumption. You might go to HTML5, for instance, but it might consume much more energy than when you create a native application. I think by making the choices visible, we will enable people to choose. We will take away the time-to-market issue and people will be able to say,’ OK, we can have this a couple of weeks later and still make things provably more energy efficient’, which consumers will appreciate.

C4C: Will we get to a stage where the consumer will think about the energy efficiency, or are they really only going to be thinking about the coolness of the product i.e. I want an iPad and I don’t really care what the energy efficiency is?

JV: Let’s be realistic about this. Consumers want to get hold of new things. They’re right – they’re consumers. So the coolness of the device has to incorporate the energy efficiency. It’s a lifestyle product. If you offer that, they’ll want it.

C4C: But in the corporate world previously, the IT department would buy the product. Now the user, the consumer, is buying the product and he or she wants a cool devices and they don’t really know about the energy efficiency side of things.

JV: If you compare it to other types of products, fridges, for instance, suppliers do compete on energy efficiency. They all want to be rated A, and that’s partly to do with regulation and partly to do with the demands of the customer. But an essential thing to make that work is that there is a measurement, a consumable rating, that’s meaningful. And now with software, we are developing the science behind it.

Is it about green hardware? Or is it using an energy efficient battery? Or just using a bigger battery? It gives you as a consumer the incentive to use it.  There is also the recycling of the batteries to be taken into account, of course.

C4C: Going back to the way the user is using the software. If you take the car analogy, ultimately there is a cost for you if you’re not driving efficiently. How do we portray those costs in terms of energy efficiency of software?

JV: Maybe you should get feedback about your consumption, not in terms of the litre of fuel you used, but in terms of euros. You want to make that last step. Similarly in software there is a lot of knowledge about CPU cycles and megabytes. But in the end you want to know what is the calorific value of what you’re doing. And that has to be put into some perspective.

C4C: If you were to take it to the nth degree, would you be able to get an idea of how much electricity or energy you had used in your browsing session?

JV: If you keep all your tabs open, do you as a user know if that has any impact, or is that negligible? If you knew it was consuming energy, maybe you’d take the trouble of closing them because it has value for you. Energy consumption goes further than simply your own device. If you’re browsing, you’re pulling information in, and the server starts doing things for you and data starts being generated. It might be stored, consuming energy, for the next 50 years. And it makes a difference how it gets archived or stored. All of this has to be made simple for the consumer to comprehend. Then there’s the organisational side, those organisations that have bespoke software built for them.

They might be interested in ‘green’ from the idealistic point of view. Their clients are interested too and they want to be socially responsible. But those organisations are also very much interested in the cost aspect. Energy costs are rising and it’s not just costs, but scarcity too. If more work implies more energy, at some point you may not be able to get it as easily as before. Either you will get it back in higher energy costs or it just won’t be there.

C4C: Is there any way you can create a benchmark or figure that talks about how much inefficient software usage can cost?

JV: Not yet. For data centre efficiency, there is the PUE. It has lots of drawbacks as well. But is has had a good impact and made choices more clear. We are working on it. We have some development of KPIs. But it’s hard. There’s a real research challenge here. One reason is the mapping of software applications to hardware. It’s not one to one. We may have one software application running on many pieces of hardware and due to virtualisation and other techniques, we have many applications running on the same hardware. With the hardware you can map how much energy goes through it. But how do you map that to the consumer of the energy i.e. the software? That’s a very difficult puzzle.

Another thing is that we’d all like to have a benchmark. To have a benchmark, you need comparable things. But think about it. You have online payments for a bank versus using a browser. The type of work you do with the software, the user transactions, so to speak, is completely different.  If one consumes a certain amount of energy and the other consumes double that, what does that mean? Does that mean the one that consumes more is worse? Not necessarily. It may simply be doing more work. So we have to develop KPIs that allow meaningful comparison. One suggestion is to how much energy per function point. That sounds good, but actually it’s completely wrong, because a function point is about functional size and how many features you offer.  Yet it doesn’t have anything about the workload in it. You have to involve the workload into the KPI otherwise it cannot work.

Now workload is something that’s completely different between different vendors and operations systems and end users. Comparing an operating system to an end user application will not work. That’s why we’re trying to build these up through the lab.

C4C: You could end up having two years of discussions between vendors over what would be an appropriate standard for energy efficient software, couldn’t you?

JV: The way to make these protracted processes shorter is to have people with lots of initiative who just go for it in their own sphere of influence, and show that it can be done, and create a reality that others can follow. International standardisation processes take a long time, but you shouldn’t wait for it. You should go for it.

Links

Software Energy Footprint Lab

8 ways to make your software more energy efficient

How the Dutch are taking a closer look at the energy efficiency of software

By David Bicknell

I am in Amsterdam to speak with a Dutch SME about its work examining the energy efficiency of software.

The Software Improvement Group (SIG) and the Hogeschool van Amsterdam (HvA) have come together to create the Software Energy Footprint Lab (SEFL).

The lab will enable researchers to examine such questions as:

  • How do different database management systems compare with each other in terms of energy consumption?
  • How do different programing languages/compilers compare in terms of energy consumption?
  • How do asynchronous requests compare to synchronous requests in terms of energy consumption?
  • How do unsigned integer arithmetic operations compare with signed arithmetic operations in terms of energy consumption?
  • How accurate are software energy profiling tools?

The laboratory will have computers rigged with sensors to measure the flow of electric current into each of the computer’s components. Specially crafted programs or generic benchmarks are then run with the sensors reporting on where the current is flowing to and how much of it is flowing to each component.

The relationship, which I’ll learn more about today, builds on the knowledge of electronics from the HvA together with SIG’s work into the technical quality of software which provides insight into the quality of organisations’ software projects, and therefore, the quality of their software suppliers.

8 ways to make your software more energy-efficient

By David Bicknell

I recently came across the Software Improvement Group, a Dutch company specialising in corporate software quality, which has produced some advice on how to make your software applications more energy-efficient. 

Its ‘quick wins’ include the following:

  • Reduce resolution of images and/or send them less frequently
  • Run multiple applications on shared servers
  • Reduce data translation between components
  • Log less
  • Delete historic data
  • Compile interpreted languages
  • Refrain from frivolous features
  • Avoid chatty protocols

The group points out that quick wins do not always apply and are only a first step towards energy efficiency. To create truly energy-efficient software applications requires attention during all phases of the development lifecycle, starting from requirements and design, through coding and testing, and finally on to deployment and operation.

Users do want efficient software