Moderator		Panelist		Panelist		Panelist
Pari Natarajan		Derek Waugh		Steve Jones		Gowri Subramanian
CEO and Co-founder, Zinnov Consulting		Director – Software Engineering, NCR		Technology Director, Cybit		Co-founder & CEO, Aspire Systems

Date: Tuesday, March 9, 2010

Time: 11 AM GMT

(Registration is Free)

Over the last several years, many packaged software vendors/ software providers have outsourced their development needs with cost-cutting in mind. However, that’s no longer the case. While having global R&D delivery capabilities are important, there’s more to it that just cost advantages.

Today, from architecture and design to development and support, offshore R&D teams are working hand-in-hand with their onsite counterparts to deliver innovative software at a faster pace and high quality. Global teams are now helping companies stay ahead of the curve, innovate and grow – and those who don’t utilize their capabilities are likely to be the ones left behind.

But not everyone reaps the benefits of globalization equally. So what are the factors that can help you leverage distributed R&D?

Join Aspire Systems for a Panel discussion on “Distributed R&D: Beyond just Cost Benefits”.  Some of the themes discussed will be:

• The impact of distributed R&D on software companies/teams
• How do you leverage software/product engineering expertise of global players?
• Challenges in outsourcing and how to overcome them?
• Globalization – myths and realities
• Best practices pertaining to globalization & distributed development

Aspire together with our customer, Biz-LX™ is organizing an informative webinar where we discuss the journey of building a software solution using Web 2.0 tools such as RIA and mashups, and demonstrate the benefits of such an exercise with a real-time case study.

In this webinar you’ll learn:

- Techniques used to design software solutions to allow better usability
- How to evaluate and select Web 2.0 techologies suitable for your software?
- The business benefits and implications of applying Web 2.0 designs to your software solution

Date: Thursday, Nov 19, 2009
Time: 11:00 AM ET/04:00 PM BST/ 09:30 PM IST

Regsitration is FREE!

Click here to register:

https://www1.gotomeeting.com/register/587477833

Panelists:

Dave Strite
Chief Information Officer, Biz-LX™

Elango Kanakaraji
Head – Web 2.0 Specialization, Aspire Systems

In software development, we have seen how the waterfall model is gradually drying up; how agile/xp/scrum has already made huge inroads; and now we are also witnessing how kanban is heralding the ‘lean’ software development. I infer that similar shifts are happening in market/customer development for software products.

A start-up that builds the software and waits for the customers to find the product will possibly remain an up-start. More often that not, start-ups fail from lack of customers, not from lack of product development methodologies. But the reality is that most companies spend more energy on building products instead of setting up a structured (and repeatable) process for customer development. It is in this context that Steve and Eric recommend a 4-step customer discovery, validation, creation and expansion process. More details are available in their blogs and so I am not going to elaborate more here. Suffice to say that within the context of this customer development model, software development needs to be executed. At least, both should happen in parallel.

PS: Doesn’t this sound like THE thing to do? Why should smart entrepreneurs need such reminders about such basics? My hunch is that entrepreneurs (romantically and rightfully) see an Apple in their companies. Ain’t a software that is good enough for them, good enough for the market???

We have a term for this in agile project management. It’s called “Truck Factor.” The name comes from the fact that when knowledge is localised, then any unexpected event–like a person getting hit by a truck–could jeopardise the project.

A Truck Factor of 1 is the worst. It means that there is some part of the system that is understood by only a single person. A Truck Factor of 2 means that at least two people understand every part of the system, and so on.

Here is how to calculate the Truck Factor for your project:

1. Go through each class, file or component
2. Calculate the number of people in the team who understand that part of the system
3. This gives you the Truck Factor for that class or component
4. The smallest of all the component truck factors is the Truck Factor for the project

Myth 1 – Usability is expensive

Among the most common myths is that usability engineering (UE) is expensive, as many big software firms invest millions in setting up UE labs and they pay usability professionals highly. But what project managers and stakeholders fail to realize is that not every firm needs to invest so much. Usability methods are flexible and can be scaled up or down according to the situation. User tests can even be run in a spare conference room and existing staff can be taught how to conduct tests. Food for thought – on an average, best practices call for spending 10% of a design budget on usability.

Myth 2 – No scientific base for testing

This myth is based on the fact that only few users are utilized in a usability test. It’s assumed that based on few people’s observation, potential problems with the product can’t be uncovered. But a number of studies have shown that just 6 to 8 users typically uncover 80% of the problems with a given interface.

Myth 3 – Usability engineering delays the launch date

This is again a very common myth that surrounds usability. Usability need not be on a grand scale starting from entire user-centered design process followed to the letter and field studies. It can be as simple as paper prototyping and can allow you to go through several different design iterations in a few hours. One of the main benefits of letting user research drive design is that testers don’t have to spend time on features that users don’t need and can focus on resources to ship the product on time.

Myth 4 – No problems=No usability engineering

Though it may look as if there are no significant user-interaction problems reported for a product, it really may not be so. In many instances, users simply don’t report problems or at times problems are misinterpreted. Whatever the reason, unless the software firm does scientific research to gather user interaction data it’s not possible to know what the real problems are or if there are problems.

Myth 5 – We have already adopted usability engineering

There are many software firms who assume that verification tests, market trials, and a feedback form when a product releases are a part of usability testing. Just by interacting with a group of potential users and gathering user data doesn’t result in real user interaction testing. You need to get users early into the picture and ask them to use the software to complete certain tasks, without being told how to. The product is then rated based on how successful users are in completing those tasks. Issues are identified during these sessions and the product is improved based on the further recommendations.

The value of usability engineering and the role of the usability engineer are still not very well understood but it’s important to know that usability is an integral part of software quality and the correct usability methods are cheap, easy to implement, and won’t delay your project.

Read the entire digest contents

For a software product to be usable, one needs to think about how and why people use a product. Understanding the user’s goals in the context of their environment and letting that determine the design is the first step to creating a usable product.

Usability engineering is an approach that puts the user, rather than the system, at the center of the process. Understanding the needs of users early is important to maintain the consistency of internal design of the software. Getting feedback through end-users’ interaction with the software at every stage and iterating based on observing users use the system is key to developing highly usable products, rather than relying on just designers’ experience.

Adoption of usability engineering throughout the development process gives users a chance to deliver feedback on the design before the product is released. Which means that even minor issues are rectified before it’s too late.

Experts believe that developers and designers should include certain essential usability characteristics for developing successful software. Interfaces are typically evaluated against a combination of these characteristics to determine how successful and satisfactory they are:

• Effectiveness – completeness and accuracy with which users achieve specified goals.
• Efficiency – speed (or accuracy) in which users can complete the task for which they use the product.
• Low Error Rate – ensures that users make fewer and easily rectifiable errors while using the system, and no catastrophic errors occur.
• Learnability – allows users to swiftly begin working with the system
  Satisfaction – makes the system a pleasure to use.
• Memorability – permits user to return to the system after a period of non-use without having to relearn everything.

Why should a development team adopt usability engineering?

• Increases productivity – allows users to focus on the tasks they want to complete with fewer distractions.
• Decreases training costs – usable systems require less training. In addition, usability testing can also identify the areas you need to focus on during training.
• Reduces development time and costs – missed requirements, workflow and design issues are identified earlier in the design meaning less cost to implement.
• Boosts sales and revenues – usability can help differentiate your software from those of your competitors. If two products are considerably equal in utility, the product with more usability will be regarded as superior.

Usability and user-centered design are iterative and typically proceeds in a cycle of hypothesis and evaluation. When followed correctly, design solutions build in richness and completeness and can provide a great user experience.

Read the entire digest contents

And this has resulted in a change in how software development takes place. From being a fully closed process, software development has been evolving towards a more community driven open source approach. Large and small enterprises and government institutions are rapidly adopting open source for three primary reasons: to reduce IT costs, deliver systems faster, and make systems more secure.

More often than not, ISVs are on the constant look out for an open source strategy that would address the demands of their customers. This could mean adopting an open source component or an entire open source license for their products. Whichever path they choose to go, open source does come with a certain amount of risk that needs to be managed.

Open source adoption is being considered everywhere, but one needs to remember that open source is far from free. And it requires an equal amount of support and services, just as proprietary software does. ISVs need to realize this and should continue offering quality professional services, which is a good revenue stream for them as well.

While open source may not work for every ISV, it’s for them to decide whether to move into the open source realm or not. That decision and the introspection that will follow will eventually help them sharpen their market focus.

Read the entire digest contents

Now, one of the approaches suggested back in the mid-90s, by James Bach, and which still holds good today is to apply an evolutionary strategy to software development. This approach is developed from the fact that as you work on a problem – it evolves and your understanding of it and your capability to solve that problem also changes or evolves. This leads to the product that is being created, evolving over time, and product knowledge also evolving.

When applied to the project level, the evolutionary strategy means ongoing process education, experimentation and adjustment, rather than clinging to a notion of one particular way of developing software. On the product level, it means planning and building the product in layers, which allows concurrent design, coding, and testing. This also provides opportunities to respond to changing requirements or unforeseen problems. On the problem level, it means keeping track of history, and learning about failure and success over time.

Some of the elements of using the evolutionary approach are:

* Don’t even try to plan everything up front.
* Converge on good enough in successive, self-contained stages.
* Integrate early and often.
* Encourage disciplined evolution of feature set and schedule over the course of the project.
* Salvage, reuse, or purchase components where feasible.
* Record and review your experience.

This approach has now become common-place, especially in relation to Rapid Application Development, but what you really need to do is to take an evolutionary view of your people, processes, and resources as well. This can lead to better software development in the long-run!

Read the entire digest contents

Consumer mashups became popular a while ago, with www.housingmaps.com being one of the earliest examples of easily and successfully merging real estate data with live map locations, to provide users a convenient way to locate apartments. More recently, the huge number of mashups created with Google Maps highlights how effectively data, code and content that is already available can be mashed-up, reused and integrated easily – even by newbie web users.

However, the enterprise mashup space hasn’t been keeping up with its consumer counterpart although many knowledge workers in the enterprise can benefit enormously from the ability to easily create and use mashups on the fly – and thereby reduce the long tail of IT demand.

Some of the reasons for the lack of adoption in enterprises are the security, compliance and integration requirements of enterprises, when combining and using data from various sources and systems. A lack of standards and formats has also been another issue that has prevented large-scale enterprise mashup use.

Vendors in the enterprise mashup tools/ platform space are however changing the dynamics of this market. In the last quarter alone, there have been several new and better 2.0 product versions of existing mashup offerings from Dreamface, JackBe, IBM, Kapow Technologies and others. Standards support for mashups have also emerged very recently.

If the current challenges involving the creation and use of mashups in the enterprise are resolved, mashups could very well turn out to be a brand new model of software development soon!

Read the entire digest contents

Many of these consumer internet start-ups got started in garages with a fairly small team and had a beta version of the product out in a matter of 6 months – more or less.

While the success of some Web 2.0 start-ups can be attributed to early-mover advantage in identifying and filling an under-served niche, there are some underlying similarities behind the successful companies.

With the limited resources available at their disposal, the key focus areas were: simplicity and usability – the intuitiveness – of the product or site, collaboration and deep involvement with the user community who are more than merely ‘users’ – they are also contributors, participants and co-creators – and constantly incorporating their feedback to make the user experience better; developing viral product features that are valuable to users like blogs and integration with other Web 2.0 tools, and ultra fast development cycles.

What does all this mean for enterprise software companies? While the consumer internet market certainly has a different user base, some of the lessons that can certainly be learnt are the simplicity and usability of software and understanding the end-user’s real needs better. If these lessons are incorporated, enterprise software has enormous potential for growth!

Read the entire digest contents