Quiz Your Company: How Well Are You Setup To Develop Great Software?

July 29, 2016 Stacey Schneider

 

36363-quiz-sfeaturedThanks to Cote, Todd Sedano and Mike Gehard for their contributions to this quiz and the resource library in this post.

Over the past half century or so, the art of developing software has elevated itself to a point where how well you develop software quite literally can make or break you in a market. Google rose from nothing to set the bar for the entire internet essentially on the ability to continuously deliver exceptional user experiences. Uber disrupted the entire taxi industry using an exceptional software experience, and without a single car to their name. The threat and promise technology presents has established companies like Allstate and Home Depot to be “all in” on becoming technology companies to secure and extend their footing in their markets.

However, in order to produce quality software at the seemingly dizzying pace these companies do, many find they must jettison many of the traditional software development practices and tools they grew up with. This even means fundamentally changing culture. Regardless of the changes, once embraced, it translates to an environment where developers become dramatically more productive, at a sustainable pace and in a friendlier workplace.

This quiz was developed to test organizations on how fluent they are in modern development techniques.

Learn More

For those that would like extra information on the topics covered in the test, here is a handy reading list that can act as a primer for learning more about the new approaches to development that can unlock software productivity and help accelerate your organization to be a modern software development shop. Of course, reading is never a comparable substitute for immersing yourself in this process live. For that, we recommend requesting to visit a Pivotal Labs site and get a tour. We are happy to invite you in and show you! Seeing is believing, after all.

  • Cross-functional teams. This is foundational to the culture shift needed to evolve our people processes to achieve Balanced Team. At its heart, it is conducive to creating empathy across teams, understanding of the task at hand and a shared shepherding of delivery process to the business and customers. This breeds into the concepts of Balanced Team, that Janice Fraser does a really nice job of explaining in this video. Kent Beck also explains it in his book that basically solidified the Extreme Programming (XP) movement.
  • Openly discuss failure. Thomas Edison said it best, “I have not failed. I’ve just found 10,000 ways that won’t work.” Failure is inevitable for everyone at some point. Accepting failure is part of a cultural change that is critical for agile teams. In fact, when running lean experiments it is better to fail fast, so you can learn and move on to another experiment more quickly. Openly discussing failures ensures the entire organization learns too, and loosens the pressure for individuals up to experiment more, which creates fertile ground for the next big idea. If the word failure still twists your insides, check out Coté’s SXSW talk, Failing fast for the uptight.
  • Continuous Integration. Continuous Integration (CI) and its siblings Continuous Deployment and Continuous Delivery, use automation to frequently test small iterations on software against the main repository. This helps catch bugs early, while also moving the code base forward faster. There are lots of tools out there to do CI, but one in particular that Pivotal is investing in is Concourse CI. Of course, we cover CI frequently on our blog too.
  • Open source. There are layers upon layers of benefits for open source. We believes using and contributing open source is pivotal to software development. Open source creates shared best practices and standards, while providing open access for using projects to accelerate development. By contributing, you also put your voice out for improvements yourself and others may benefit by achieving, and reward your smart developers with recognition for their work in public forums.
  • 12-Factor app. This is a methodology originally designed to guide building software-as-a-service (SaaS) apps born from the experience of building hundreds of them on Heroku. The structure of these apps is somewhat rigid, but are designed to afford your apps to evolve quickly. The go-to resource for its standard definition is 12-factor.net. However, Pivotal’s Kevin Hoffman has expand upon the process and added three more factors in his book, Beyond the Twelve-Factor App, something he explains in more detail on a recent podcast.
  • Container orchestration. Portability. Scalability. Resiliency. Simplicity. If you automate your container orchestration, you set yourself to get all of these benefits. You think some poor schlub is sitting in a Google data center manually scaling up services by adding servers to clusters? No way. Long ago they did away with that and automated it. Docker Swarm and Google’s Kubernetes are popular projects for container orchestration. Cloud Foundry also has BOSH, which layers in more of the app level orchestration. The differences and benefits are subtle, and probably best explained in this Stackoverflow answer.
  • Eliminate the bus factor. There is a phrase that states your best developer is your biggest problem. The more important information that is locked away to one person’s brain, or job, the more at risk that the entire organization will weaken or fail if they get hit by a bus. Or even if they get burnt out because you are always calling on them for heroics, a hole they dug themselves by hoarding information. We remove knowledge silos by rotating developers. At Pivotal, we rotate developers frequently and often around the whole project. It creates a better understanding and better code for the project, as well as learning for their own personal development skills. Pivots listed this as one of the top 21 reasons that the Pivotal Way attracts top software talent.
  • Short software development cycles. If your development cycle is longer than 2 weeks, then you are doing it wrong. Your scope is too big, and risk of failure is high. This is exactly the reason why Extreme Programming evolved from Agile, to shorten the development cycles and reduce friction or risk to developer velocity, a measure of how much good code any set of developers can churn out. It also has the happy byproduct of meaning your customers get more frequent updates and improvements, which improves customer satisfaction and potentially security. The extremeprogramming.org site has more info on structuring your iterations, and we recommend watching Eric Reis talk about how to identify the right Minimum Viable Product (MVP) to align what goes in those iterations.
  • Big data is operationalized in apps. North of 90% of the world’s data is dark, meaning it is not being actively accessed or used. Good companies will interrogate their data periodically and suss out some insights to influence their go forward strategy. The best companies bake analytics into their system to create real-time exceptional user experiences. This is a fundamental shift in your approach to data, which is why some Pivots say, “Business Intelligence Is Dead, Long Live Business Intelligence”. Take a look at these 20 examples of ROI and results using big data, and to get your fingers dirty, we really recommend looking at the Spring Cloud project.
  • Pair programming. Sitting two developers down together all day at one machine, with two keyboards and two monitors may seem redundant at first. Peel away your skepticism and you realize this creates an atmosphere of focus on the task, of extreme learning and of support to solve problems fast. One Pivot, Maryam Labib notes in her report Pivotal process life hacks, that “pairing is life skills 101”. Pairing is part of XP, but if you still think it doesn’t make economic sense, check out this study that found “for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.”
  • Microservices. The idea is to build software services that can be loosely coupled, and are small enough that to replace or refactor one will be independent of the rest of the system. Again, the goal here is to open up your app to be quickly evolved. Martin Fowler, the international speaker who wrote the Manifesto for Agile Software Development in 2001, gave a great overview of the nine characteristics that are intrinsic to microservices in this video. We are also big proponents of this movement, and frequently cover it on our blog.
  • Test driven development (TDD). This is writing a failing test before we write the production code. This does a lot. It makes developers think through their pitfalls before writing. It speeds up testing and acceptance because that is ready when the code is ready. It organizes the steps in development to be enormously more efficient. To put this in perspective, check out David Julia’s TDD Midlife Crisis: White-Box Testing & Refactoring Tests which shares his experience as laid out against Kent Beck’s TDD-defining book, Test-Driven Development By Example.
  • Cloud native platform. If the goal here is to automate all the proverbial SH out of IT, then it’s obvious why you need to run on an automated platform. In order to take full advantage of the promise of cloud computing, you’ll also want that platform to be optimized for the native tooling. Basically, you’ll want a flavor of Cloud Foundry. The benefits here are wide, and the roadmap is even more exciting for Pivotal Cloud Foundry. A recent post summed it up nicely of what happens after the last line of code is written. Deploying in 45 seconds is a lot more rewarding than waiting 15 days or more, which is the average. Check out our cloud native journey series, both the business side and the technical side, to really paint a picture of the possibilities here.
  • Zero downtime. Fail whale be damned. In today’s day and age, there is no excuse to have your whole business down. This is why we want to build services that can easily be swapped. There is a lot more to zero downtime ranging from how you deploy with blue-green deployments to continuous delivery pipelines. Check out how we do it on our own Pivotal Web Services, our hosted Pivotal Cloud Foundry service.
  • Sustainable pace. Since we are aiming to change all that is broken, uncomfortable or risky in the software development process, why would we not look out for number one? That means YOU. Pivotal has studied sustainable software development at length, aiming to make sure that developers build skills faster, are more consistently delivering software they are proud of, and work in a much nicer environment. One that will not burn them out. At Pivotal, we produce tons of code that, more importantly, drives tons of business value. With a productive day tucked away in their back pockets, developers start work at the same time every day and regularly spill out home at the same time to have a social life, to have a family life or whatever kind of life they need to be refreshed and recharged for the next, predictable, productive day at the office. For businesses, this also helps to attract and retain top talent. It’s a win-win for all.
  • DevOps. DevOps sprang from Agile and Lean methodologies being applied to System Administration disciplines. It works to fuse the gap between IT and developers and get both groups to use the same systems and processes and allows fluidity between the disciplines. The Agile Admin provides a more in depth overview. We cover devops topics frequently on the Pivotal blog, and recommend attending a DevOpsDays event near you.

 

About the Author

Biography

More Content by Stacey Schneider
Previous
SpringOne Platform—A Movement Comes of Age
SpringOne Platform—A Movement Comes of Age

Today, over 2,000 faithful from more than 400 companies large and small have come together on the hot-baked...

Next
Building A Rich Model Factory With MPP
Building A Rich Model Factory With MPP

In this post, Pivotal Data Scientist, Scott Hajek, explains how to effectively utilize an MPP database as a...

×

Subscribe to our Newsletter

Thank you!
Error - something went wrong!