High Performance Software Engineering Teams


Published on

Based on my experiences building high performance engineering teams, this presentation focuses on the technical practices required. These practices centers around automation (build, test and deployment) and increased collaboration between Engineering and QA (TDD, exploratory testing, prioritization, feedback cycles).

Published in: Technology

High Performance Software Engineering Teams

  1. 1. High Performance Engineering TeamsThe Technical PracticesLars ThorupZeaLake Software ConsultingOctober 18, 2011
  2. 2. Who is Lars Thorup?● Managing software development ● 10 years of agile practices ● 15 years of automated testing● Introducing agile and automated testing with clients● Assessing software projects and companies● Founder of 2 agile consulting companies ● 12+ senior consultants ● 10+ years
  3. 3. What is a High Performing Team?● Short time from getting idea to going live ● weeks instead of months or more● Faster development● Higher quality● Lots of experience from industry how to accomplish this
  4. 4. How to become faster?● Stop doing non-productive things! ● Manual regression testing ● Bug hunting and debugging ● Implementing more than required ● Out-of-date documentation ● Piling up bug reports ● Rediscovering of knowledge ● Working on stuff not in the value stream
  5. 5. How to increase quality?● Test more thoroughly● Test more often● Test cheaper
  6. 6. Automate!● Software companies tell their clients to automate to increase productivity and quality● This advice also applies to the software development itself!
  7. 7. Shorten the feedback cycle● Automate testing ● from weeks to minutes● Close collaboration between Engineering and QA ● from weeks to hours
  8. 8. Dont track bugs - fix them!● Real bugs are always top priority ● Fix before working on anything on the backlog● Decide if an issue is a real bug or an (unwanted) feature● Prioritize (unwanted) features into the backlog● Purge your backlog
  9. 9. Automate the build● Compile code and installers ● Have a visible dashboard to show status● Run tests ● on every commit ● Notify about broken builds ● Top-top priority● Deploy to internal servers ● "Stop the line" and production ● How can we prevent this type ● at the push of a button of break in the future?
  10. 10. Automate the testing● Unit tests ● Is the code doing things right? ● Test one piece of code in isolation● Acceptance tests ● Is the code doing the right things? ● Test the integration of all layers of code
  11. 11. Automated unit testing● Use a unit testing ● Track coverage for new framework for each code programming platform you ● Aim for 75% use ● ... and more for important code ● Java: JUnit ● Include on the dashboard ● C++: UnitTest++, Google Test ● JavaScript: Jasmine, QUnit ● SQL: Probably JUnit
  12. 12. Automated acceptance testing● Test through the UI if you must ● ...as little as reasonably possible● Test just below the UI if you can ● Use your existing unit testing framework● Consider an acceptance testing framework ● like Cucumber
  13. 13. Test Driven Development● Write tests before writing the code to make them pass● Not a testing technique! ● but a design technique● Makes it easy to write tests ● keeping coverage high● Makes the design flexible● Improves communication between Engineering and QA● Speeds up development
  14. 14. Continuous integration - Continuous delivery● Each commit to the version control system ● triggers an automated build ● triggers an automated deployment● Expect developers to commit several times a day
  15. 15. Collaboration between Engineering and QA● QA can test the code as soon as possible● Before it is written ● TDD collaboration ● Write automated acceptance tests● Just after it is written (same day) ● Continuous Delivery makes it available ● Exploratory testing ● Scenarios the developer didnt think about ● Make this step part of "done" for stories● Dont keep a large backlog of untested stories ● Engineering can help QA on testing if required
  16. 16. But: what about legacy code?● Add pinning tests ● special kinds of unit tests for legacy code ● verifies existing behaviour ● acts as a safety net● Can be driven by change requests● Refactor the code to be able to write unit tests● Add unit test for the change request● Track coverage trend for existing code ● and make sure it grows
  17. 17. But: "we cant change the company this much"● Yes you can! ● It requires ● Enthusiasm● Others have done it before ● Support you ● Willingness to invest ● Transparency
  18. 18. But: <your question here>
  19. 19. References● "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" by Jez Humble and David Farley● Local software companies following these practices with success ● Wealthfront, Palo Alto ● IMVU, Mountain View ● Salesforce, San Francisco ● Pivotal Labs, San Francisco ● ...