Posts Tagged ‘software’

Three Surprises in Software Development in 2012

December 8th, 2011 by lorne cooper

‘Tis the season to make unsupportable predictions for the future.  Despite my prior record (and I remain surprised that we don’t yet have personal jet packs) I’d still like to share a long-range weather forecast for the software industry.

You’ve been warned.  From here on, you’re on your own.

Prediction 1: Everyone Will Claim They Are Agile

And 50% of them will be wrong, just based on the Nokia test.  And of the rest, half won’t get any value from it.

There are a lot, and here I really need to underline a lot, of bad development practices out there.  For every organization that is killing it with Agile, there are five (my agilesta friends say ten) organizations that are limping along, delivering buggy code to their customers, late, and missing committed functionality.  And often all three.

This “Going Agile Without Knowing How” problem is probably an inevitable result of the success the early-adopter teams had with Agile methods.  For instance, when I watch The Olympics, figure skaters make skating look effortless.  When I do it, I look like a drunken hippo and hurt my butt.  It’s hard to stop and remember that these athletes, in addition to good genetics, spent years at the rink with their coaches learning, trying, failing, and improving, before they got in front of the TV cameras.

Agile has crossed the chasm, and the great majority of organizations have too few people, with too little coaching, and hardly any tooling.  Sure, your boss doesn’t realize how useless your stand-up meetings are, or that your code isn’t fully tested at the end of a sprint, but she’ll eventually see that your customers are not happy.

Prediction 2: Development for Mobile Devices Will Still be Small

Yes, Mobile is really big, and moving fast.  It’s just that the great majority of the work to support useful mobile apps remains in the back office.  When we’re finished inventing new ways to swipe our coffee-stained fingers across our screens, the value of the great majority of our apps is back in the glass house, running Java and C++ on big ‘ole honking (virtualized) servers.

The development problem in the era of proliferating small platforms, remains the problem of dealing with large, complex, data and it’s interactions.

Sleep well, Larry Ellison.

Prediction 3: The Gap Between Pros And Amateurs Will Grow

Every new software technology “spike” rewards the early adopters with higher productivity, which can level the playing field for the “newbie” or occasional software developer.  But as application complexity grows, as the platforms become more complex and development environments become richer, the professional advantage becomes more significant.

There isn’t much of a disadvantage in time-to-market for the young developer, maybe working on his laptop with open source tools and no identifiable process. The difference between them and a team of experienced professionals, working with industrial strength tools and procedures, and building apps that run businesses on virtualized hardware in a web connected world, is in “value created.”

Created Value is a concept that we’ve all been learning during the past ten years of Agile evangelism.  Created Value is measured at the customer side, and primarily by the classic metrics of software: how does the software help me get my job done better and faster?

There was a time when the lowest cost labour source for a software project was the key criteria.  Over the past two years, software projects have been revisiting their decisions as they’ve seen the crippling effects of buggy, unmaintainable, badly architected products.  We’ve seen the evidence with a hiring boom in the US for developers and QA alike.

In short, in 2012, we’ll see a renewed focus on quality of development, over quantity.  And a better appreciation for the talent, tools, and techniques, that create it.

 

SCM Best Practices and Continuous Integration Go Hand-in-Hand

June 15th, 2011 by AccuRev

There’s no denying that this has certainly been the Agile decade for the software development industry.  It’s evident all around us in this tenth year since the Agile Manifesto was created. Most companies and development organizations today have implemented some form or aspect of Agile methodology into their software development processes. Whether you’re aiming for pure Agile or a mixed/hybrid approach, proven best practices in all phases of the software development lifecycle are crucial to success.

This is especially true in the case of continuous integration, one of the foundational aspects of the Agile methodology. The concept of continuous integration, as defined by Martin Fowler, is “a fully automated and reproducible build, including testing, that runs many times a day.  This allows each developer to integrate daily, thus reducing integration problems.”

With this approach, developers can work more closely in parallel while identify problems and debugging on the fly, accelerating the development process and improving the quality of the finished product.  The benefits of continuous integration are tremendous, but can quickly be eradicated if software configuration management (SCM) best practices are not carefully followed.

There are a handful of SCM best practices that can optimize continuous integration.   Let’s start with a quick look at the first two:

  • Using an SCM system to store and version all source code
  • Utilizing private developer workspaces

Best Practice: Using an SCM System to Store and Version all Source Code

Parallel development and distributed software teams can make tracking changes a daunting task, especially with the frequent changes that occur when using continuous integration methods.

For this reason, it is important to employ a software configuration management (SCM) system to strictly version changes to the code base. In addition to versioning source code, everything needed to build the system should be placed under version control, including the following:

  • Third-party libraries
  • Properties files
  • Database schema
  • Test scripts
  • Install scripts

All developers should have at least read-only access to all files needed for the build and should obtain all such files directly from the SCM system. This approach ensures that developers are working with the latest build environment, and is preferable to the common but error-prone practice of placing such files on a shared file server.

To effectively implement continuous integration, all development groups should work from the same central source code repository so that the latest changes from other developers are easily and immediately available.

Best Practice: Utilizing Private Developer Workspaces

In order to fully realize the benefits of continuous integration, software development organizations need to ensure that developers can remain productive regardless of the overall state and stability of the project source code. To achieve this, private workspaces that give developers full SCM capability should be used. Private workspaces enable developers to

  • work in isolation
  • revert to known “good” states when needed
  • checkpoint their changes
  • share only mature, well-tested code with other team members

The benefits of isolation are bidirectional—it protects developers from incoming changes, and protects the shared code configuration from incomplete or incorrect changes from any one developer. By creating private workspaces, developers receive all the benefits of SCM for their personal use, including the ability to revert to a previous state, viewing and tracking of changes between software configurations, and setting aside changes to begin work on a different task.

Once a new known good state is reached (for example, when a developer completes engineering and testing work on a feature), developers should checkpoint their work, typically by “checking in” or “keeping” the local changes in the SCM system. The checkpoint ensures that the developer’s work is safe on the SCM server and that the checkpoint can be revisited at any time. However, since the changes have not been shared, other developers and teams are not affected.

When a developer breaks isolation and decides to share a code change, he or she is essentially making an assertion that the change has reached a higher level of maturity. This, coupled with the use of local developer builds, helps to ensure that only mature, well-tested code is passed on to the rest of the development team, a primary benefit of continuous integration.

Are You Part of a Scrum Team or Scrum Group?

March 14th, 2011 by LLowry

I remember the first time I heard the term scrum development.  A manager at a previous job told me “We’re doing Scrum now, read this.” Then he handed me bunch of photocopied book pages.

After a comprehensive review of the pages, all I figured out was that Scrum had something to do with fast meetings every morning. And that was my first introduction to Scrum.

At a later job, I found myself in a meeting, brainstorming the best way to make Scrum work internally, and arguing over what Scrum was supposed to look like. Both situations, a minimally explained stack of photocopies, and arguments over the physicality of Scrum, resulted in negativity- people around me decided that “Scrum doesn’t work.”

How Scrum Works

In my situations, trying to make Scrum work took precedence over the team, and whether or not it could really take advantage of Scrum practices. Taking advantage of Scrum practices is what makes a Scrum team succeed. After all, the development term “Scrum” was derived from rugby for a reason.

The name Scrum was chosen to represent specific software development practices because like Scrum team in rugby, one team needs to cover a variety of responsibilities. This team works towards a common goal, continuously, in parallel, and under circumstances that could, and do, change rapidly. In rugby, the Scrum team needs to cover ground together. The clock never stops, teams never switch sides, and the ball can only be thrown backwards or sideways, forcing the team to move together in a line across the field. Similarly to Scrum in development, all team members need to know their teammates status, so they become aware of new gaps in the field position that need to be covered. In this aspect, the team needs to be self-managing, while it pushes the ball forward in sprints. This can’t wait for outside direction.

If your team is new to scrum, or struggling with it, the tendency to blame Scrum practices instead of a team’s unity often highlights deeper problems. If a member of a rugby team isn’t keeping up and leaves a gap in the line, no one would say ‘rugby doesn’t work’. The word ‘team’ gets thrown around business a lot when ‘group’ would be a better description. A team communicates with each other, strategizes, and members know how to truly work together- not just in parallel.

Functioning as a Scrum Team

In the film Invictus, Nelson Mandella tells the captain of the South African national rugby team that he needs them to win the world cup to gain the support of the nation. Players complain that their schedules are already full, and extra work like running rugby clinics for children isn’t worth their time. But after working together on these clinics, the team became much more focused and productive when it came to new responsibilities. As the captain said “We’re more than a rugby team now, we need to get used to it”.

The expectation to function as a team is built into scrum. If a group has seen previous success without having to self manage, or without leaving their keyboards for things like planning meetings, there will naturally be complaints that scrum isn’t working. In some cases teams may need to tweak Scrum in order to fit a specific organization, but before making changes it’s worth looking to see if your team is functioning like a team, or like a group.