Software development is a fast-moving space. What works for a project today doesn’t always work for the same project tomorrow. But the reality is that when you’re looking for a software development vendor you’re going to evaluate knowledge of the technical stack such as programming languages, libraries, frameworks, architectures, and APIs as well as tools, development methodology, similar work experience, etc. The question is: what are required skills and experience vs. what can be learned without adding risk to your project?
Beyond basic knowledge and skills, it’s more important that your vendor have a learning orientation than specific technical knowledge at the moment you encounter them. Just as importantly, your vendor must have an internal culture and structure that supports continuous learning and cross training. This allows you and your vendor to move from a boxed-in discussion of options to a true brainstorm that results in a better product.
Here are a few examples of our approach to learning in action.
Must know Xamarin—no exceptions?
Last year we engaged in discussion with a soft drink manufacturer and distributor. They were vetting vendors to develop a mobile application that would allow its global sales team to do real-time analysis and planning in the field with their clients. They were late and over budget. The application was built on Xamarin and the head of software development was looking for developers with deep Xamarin experience. The problem was that Xamarin was hot, Xamarin developers were in demand, and therefore difficult to find and expensive to hire.
We were very open with the head of software development. We had a small team of developers with Xamarin experience. Some of our staff had very recent, hands-on experience, others had experience working on a project 12+ months ago, and still others had only worked on PoCs (proofs of concept–not what we would define as a “real project”). Nevertheless, the client chose us for our integrity, commitment, knowledge, analytical minds, and comprehensive approach. They assessed the project timeline, our ability to ramp up, and decided to move forward with our team. Here’s how we gained technical knowledge fast:
- We hired a Xamarin expert to provide an intense Xamarin immersion for our team. This expert joined the project team, advised on architecture/approach, and coded alongside our team for two months to ensure we exceeded velocity expectations. This was an investment we made at no cost to the client.
- We assigned to the team both our strongest Xamarin developers and shadow developers with light experience. For example, if the sprint required three developers, we assigned five. In this way shadow developers learned by coding alongside the experienced team. Once the shadow developers learned enough to work on simple tasks independently, their contributions ensured the experienced developers had space to mentor and teach complex concepts without impacting velocity.
- Because of a strong baseline of related technical knowledge the learning process was fast. In particular, like the client, we are a .NET shop, plus the team already knew XAML (eXtensible Application Markup Language, Microsoft’s variant of XML for describing a GUI).
We were not originally asked to participate in testing, but seized an opportunity to both learn and leverage Xamarin Test Cloud. We added one of our most seasoned test automation engineers to the team and gave him space to learn and run a Xamarin Test Cloud PoC. The client’s internal team was so pleased with the results that we began working alongside them and taught them to leverage Xamarin Test Cloud themselves. In this way our project involvement grew from development only to include test automation.
You say we have to use Angular 2. Isn’t that still in beta?
Another client insisted on using Angular 2 for development of her very data-driven web application. Angular 2 theoretically would allow much more optimal management of data but at the time we were adopting it, it had little to no support from the technical community.
Did we agree with this approach? Well, at first, no. It was risky. How could we protect our client, we wondered when we’re using an unsupported framework to build their application? But we certainly made the best of it and guess what? Things worked out great.
We approached the challenge this way:
- We added bandwidth to give our developers space to learn Angular 2. In addition to shadow developers, the Integrant team’s technical lead would jump into a sprint and work on stories.
- Just in the nick of time, a supporting tool, called Redux came into play. Redux was a new convention in how front-end apps consume data, and it paired beautifully with Angular 2.
It turned out to be great because Redux was introduced to support Angular 2 in time for the Integrant team to finalize integration. If Redux had not been introduced, would the use of Angular 2 have succeeded? Maybe not. But we took this as an opportunity to learn and grow with the client. We ended up going from unsupported Angular 2 to upgrading to Angular 4 during the course of the project. Investment well made!
DDD: the perfect solution, and we need to know it–now
A start-up client in the property management industry hired us to do what two previous vendors had failed to do—get his financial modeling and reporting web application over the finish line. He vetted us intensely for our business intelligence and mathematical modeling knowledge and we passed with flying colors. That was the good news….
The client’s technical lead insisted on using DDD (domain driven design). And for good reason. DDD forces a common language to be used in developing and speaking about the application.
Integrant’s technical lead knew DDD very well, but his team had only been exposed to it on a cursory level. The challenge for the developers to learn DDD without disrupting the project timeline.
- The technical lead followed a different approach for each programmer. For the more tactile developer, he worked elbow to elbow to go over code and move it into DDD. For the other programmer, more of a linear thinker, he supplied text books and assignments which they reviewed together. In both cases the technical lead would at times jump in and code during a sprint to allow the developers to focus on a PoC using DDD.
- Sometimes elbow grease is an important ingredient! To maximize synergies, the team insisted on working side by side at the office no matter how late the day went or how early it began. The support associated with “being in it together” meant better, faster work.
The most rewarding aspect of all this? DDD was indeed the right approach and our team had the glory of making a great application a reality.
Converting C++ to .NET and C#–without the device, or knowledge of C++
A biotech client needed a web application built to support data collection, download, and analysis from multiple study sites during clinical trials. The download utility software needed to be converted from C++ to C# including serial ports and low level APIs. The client had assured us we would not need knowledge of C++, a good thing, as we’re a C# shop. But because of regulatory issues the client couldn’t get the Integrant team access to the legacy device until 30 days into the project.
The team would need to make its own emulator of the device in C# and use open source tools to make virtual communication ports on Windows. They would need to compile the existing code to test and debug the legacy app. This would give them a good sense of how the C++ code was dealing with communication serial ports, different cases, and normal workflow of data.
- The diversity of professional maturity among team members at Integrant means that these types of situations can be addressed. Integrant’s technical lead had two decades of experience and was an expert in C++. Sometimes a senior developer will teach a new developer a legacy language and sometimes a new developer would teach a senior developer a new method or tool. Mentorship goes both ways and in this case it ensured optimal conversion of C++ code.
- When dealing with C++ conversion, the technical lead would sit side by side with the programmer to dig into the issue. They used pair programming concepts for knowledge transfer. The two would share thoughts and suggestions on how to investigate the issue, identify the root cause, and resolve it. Sometimes there were multiple solutions and the discussion focused on choosing the best one. The result was a successful conversion and increased depth of knowledge for the client’s team.
In this way we moved the relationship with our client into the “trusted partner” zone that really can only be earned when the going gets tough.
Grey hairs meet millenials: match made in heaven?
A few things allowed these scenarios to end in success. When you’re interviewing your existing vendor or vetting a new one, ask some questions around the following to see how they handle new technology:
- Recruiting: Does your vendor hire for skills, or for attitude? Both, but what’s the proportion of each? Some vendors recruit for 80% technical genius and 20% awesome attitude. We are the opposite, as it’s much less expensive to teach a language than it is to teach concern. One’s a skill, the other is a core value.
- Growth mindset: Is your vendor open to your input? Are they open to new technologies and methods? If you read our employee profiles you’ll see that most of our team members are known among their peers for things like being a tenacious problem solver, having an insane attention to detail, or helping out their colleagues.
- Training: Does your vendor have an approach to training that they can describe? If so, it’s most likely important to them. For us, we provide scheduled, ongoing training on technologies that we anticipate to be important and those that our new-hires may not be up to speed on. Also, effective training involves tailoring learning styles based upon the student.
- Bench: Does your vendor have built-in backup? If a new technology needs to be learned, and fast, having bench allows the team to get up to speed without compromising velocity on your project.
- Culture: Ageism is real and there’s really no place for it in a success driven software shop. Sometimes a senior person struggles with TDD but has a lot to teach the newbies about code structure and architecture. A newbie may pick up C++ in a heartbeat. This is learning, both backwards and forwards.
If you’re talking to a current or prospective vendor and they have a technical gap, ask them if and how they can address that. You will learn an incredible amount about their culture, their systems, and their commitment!