The new employee selection and hiring process is important for any business, but it is uniquely important, and uniquely difficult, for software development organizations. Many organizations conduct a hiring process that overemphasizes the assessment of some of the candidate’s qualities, while ignoring others that may be more important. A balanced approach, and more reasonable expectations, can lead to a more efficient hiring process. Continue reading
By Chris Durand CTO, Bridge360
Want a guaranteed way to reduce your spend on software development? Do less. Really. Testing too expensive? Test less! Development too expensive? Develop less! Does this sound too good to be true? The good news is that most teams can benefit tremendously from this approach. The trick is to identify what to do less of.
By Chris McIntosh, Senior Software Developer
We have all seen the various studies of software development and the causes of failures to deliver on time and cost overruns. The original Chaos report stated that a mere 16.2% of projects finished on time and budget. There have also been numerous studies surrounding the cost of defects and how it varies depending on when in the lifecycle they are discovered. The consensus, first reported on by Barry Boehm in the 80’s, is that the later in the software process a defect is discovered, the more expensive it becomes. There is some debate as to whether or not this is a hard and fast rule, but suffice to say, defects are rarely free to fix. Agile has cropped up to try and address some of these issues. It has certainly helped. A more recent report on software project failures puts it at 50% – 70% of projects are finishing on time and budget, with the projects using more agile techniques in the upper end of the spectrum. Agile practices are successful in reducing the failure rate by, in part, making the team test the development more frequently and elicit requirements more often. This is wholly dependent on your team’s ability to gather, record, and test requirements efficiently.
Here are some simple techniques that you can slowly introduce to decrease the defect rate due to poor requirements.
by Rema Sreedharakurup, Senior Quality Assurance Engineer
It seems today that no discussion about software development is done until someone brings up ‘Agile.’ And for good reason, as Agile is all about agility – an Incremental and iterative delivery model which focuses on business value, encourages flexibility and rapid adoption to change. It’s based on collaborative efforts to achieve common goals.
The agile principles & values are very short and sweet, but in the real world, Agile is not that simple. Remember, it’s a collaborative effort that requires people – Developers, Testers, all the folks involved in the product development who are trying to perform their best in this transforming phase and get things DONE… all the while trying to get accustomed to new processes that get introduced to improve delivery, and where output is expected quickly. Though, as Albert Einstein once said, “in middle of difficulty lies opportunity.” Hence for me as a Test Engineer, this transition to Agile opened up a wide array of opportunity where I could wear many hats – as a developer, as a tester, a customer advocate, a constant learner, and much more.
Here’s how I see each of these hats fitting my head, and perhaps yours, too. Continue reading
by Benjamin Frech, Senior Software Engineer
Increasing a team’s productivity is a ubiquitous goal. But, how do you achieve that goal?
To many, it may be tempting to use velocity as a measure of productivity, but the value of a story point can vary significantly over time. Once you get past counterproductive answers like, “let’s inflate all our story points by 50%,” you’re left with options that can actually increase your team’s productivity or, at least, facilitate collaboration between team members.
In my experience, the top two methods of truly increasing productivity involve creating a comfortable work environment, and addressing technical debt and developer concerns. Continue reading
by Chris Durand, CTO
Are you looking for new way to solve pressing technical problems? Well, I’ve found one, and I recommend it for anyone looking for a fast way to start a problem-solving process. I call it the “straw man” technique, and it’s pretty straightforward:
- Think of the simplest possible solution or partial solution for a problem. This is the “straw man.”
- Discuss with your team reasons why you think the solution will work or not. My favorite question to ask is, “Why won’t this work?”
- Modify the straw man accordingly and repeat until you have a useful solution.
That’s it! I find myself using the straw man technique often; you can, too. Imagine you and your team are looking for answers on how to solve a challenging problem or implement what appears to be a complex feature. Think of a super simple solution that addresses at least 50-60% of the problem and ask the team why it won’t work. Then iterate from there until you reveal an acceptable solution. Continue reading
by Diane Kenyon, VP of Engineering and Operations
Benjamin Franklin famously stated that, “an ounce of prevention is worth a pound of cure.” In the world of quality software, that analogy may be underestimated. Errors in software development discovered at the release stage are greatly more expensive and difficult to repair than when discovered during the testing and development stages.
While there are no guarantees of perfect success, establishing best practices for development and properly educating your team of those guidelines will significantly reduce the likelihood of errors and diminish their impact. The key lies in making sure everyone knows the rules to the point of being able to quote them, and that each person understands his/her responsibilities within the project. Culture, compliance needs, expectations and risks all go into establishing a framework for success.
Following this structured process for defining and hardening your best practices improves consistent adoption across all team members: Continue reading
by Morgan McCollough, Senior Software Engineer
In the first week of June, I made the trek to Caesar’s Palace in Las Vegas to attend the Agile Development and Better Software Conference. The conference itself was only two days, but I attended a three-day Agile scrum master training class beforehand. It rounded out a full week immersed in all things Agile.
I’ve worked with a number of clients who claimed to have adopted Agile in one form or another. I’ve also read quite a bit about it, but prior to my week in Las Vegas, I had never received any formal training. The trip was eye opening, and it was a great opportunity to talk with people from across the industry.
What really became obvious was just how many companies are successfully implementing Agile processes at both the software development and program management levels. Some are achieving pretty dramatic results, with up to 30% shorter schedules and 75% fewer defects on average! However, learning the formal practice of Agile also made it clear how much dysfunction still exists, even in companies claiming the Agile moniker. Continue reading
By Brenda Hall, CEO
Here’s some great news: despite whatever views we may have of how unemployment figures are determined, the economy continues to recover. In many parts of the US, a number of jobs are not getting filled; this also holds true for offshore staffing companies. I know many recruiters who are having difficulty keeping up with demand and finding an adequate number of candidates with the skills employers need.
Frequently, as businesses grow and need to scale, owners and managers find they have too much to do and not enough time to do it, so they pay less attention to the offshore/outsourced resources available to them. Taking your ‘eye off the ball’ here can cause havoc with your teams, both locally and offshore.
Some questions to consider:
How does offshore sourcing affect your productivity and product quality? What will you do when release schedules are missed, or worse, your software is released with issues? How does this influence your corporate strategic goals and customer satisfaction? Continue reading
by Chris Durand, CTO
Let’s be honest, Quality Assurance is a necessary evil. Many of you have probably wondered why developers can’t just get it right the first time. Why do we pay developers to write bugs, and then pay testers to go and find them?
The answer simply stated is — writing software is hard. Software developers need to be extremely detail oriented, yet also keep the big picture in mind. They must balance short-term tradeoffs with long-term considerations. They often have to learn new tools and technologies with each project while balancing the demands of outside influencers. Oh, you needed that feature or bug fix done yesterday? And you want that application to work on all browsers released in the last 3 years (that’s 24 versions of Google Chrome alone since March 2011), plus mobile? It’s no wonder developers struggle to write perfect code every time.
While it can produce quality results, the old model of throwing code over the wall from the development team to the QA team is inefficient. We that build software have to do more for less, faster, and in a more complex environment than ever before. The rise of automated unit testing and Test- or Behavior-Driven Development (TDD and BDD) is an attempt to realize improvements. By testing at the core (that is, with the developer), we find bugs as early as possible (which yields tremendous savings as discussed in the post https://bridge360blog.com/2013/12/04/5-ways-qa-supports-development/). Automated unit testing also makes it easier to update the application going forward by identifying unexpected broken dependencies in the code before they get in front of a customer. Continue reading