Scaling up and not bottoming out

1. Scaling up and not bottoming out a story of Process Improvement Presented at CoastNerds 16-May-2012, Robert Dyball

2. The Product • Preactor – scheduling software • Used in over 3500 companies in 67 countries • Can model machines, packing lines, tanks, assembly lines for make to order, make to stock, engineer to order, in continuous and repetitive processes. • Used in a wide range of small, medium and large enterprises from small fabricating shops, to chemical plants, pharmaceutical, food, and beverage manufacturers to mining, shipping and airport scheduling.

3. Preactor • A brief demonstration of the Preactor product

4. The Pleasure • Niche market • Well respected brand, few worthy competitors • Scheduling tools built into most MRP and ERP systems typically primitive compared to Preactor • Businesses using the scheduling tools become more profitable; retain market share and local competitiveness even in hard times • Preactor API allows additional functions to be added, providing opportunities for integration and enhanced reporting as well “shop floor” interfaces.

5. The Pain • Preactor can work stand alone, but most clients require integration to existing ERP/MRP systems. • Integration to ERP, MRP systems typically using CSV • Some industries have very complex rules, e.g., food and pharmaceuticals have to perform expensive cleaning operations between different products in addition scheduled cleans. • Some schedules have constraints in 6 or 7 dimensions • Many clients do not know their own scheduling “rules” • Many clients discover requirements on the fly, during the project (so what is new!)

6. The Possibilities • Limit projects to easy wins, to “low hanging fruit”or • Implement process improvementbut what and how?

7. Agile Development • If you aren’t using some form of agile development, see what you can use from Scrum, Kanban or XP • Projects become more predictable and repeatable • Project costs will be lowered • Teams will grow in capability • Teams become more responsive to change • Scope is managed • Customers benefit, being delivered a product that is closer to their needs

8. TFD: Test First Development TDD:Test Driven Development • Proven to create better solution designs, with less bad coupling = more maintainable code • Provides safeguards when refactoring • 10% more effort now (with TFD/TDD)or 50% more effort later (without TDD) • A suite of tests built up during the life of the project provide valuable feedback when performance testing • Tests may replace most traditional documentation, and provide “living” documentation beside the code

9. ATDD and BDD • Acceptance Test Driven Development (ATDD) or Behaviour Driven Development (BDD) will sift out the poorly spec’d out user stories, allowing less scope shift and faster development • BDD tests can be automated providing fast response to the team and to users, faster turnaround of work • BDD tests create a common language that everyone can “speak” – users, developers, testers, managers • BDD tests provide living project documentation • BDD can be applied to smaller or larger units of work

10. Source Control/Version Control • Must be fast and reliable • Must be simple to use • Handy if it is also inexpensive • We have adopted GIT – using local repositories as well as a central repository • Git has offline capabilities and works well with peer-to-peer push/pull • eg., desktop local repo <-> USB stick repo <-> laptop

11. GIT Can your source control do this? If not, get Git.

12. The Friction: • If done manually:- manual testing gets boring and quality drops off- manual builds can become too much work- source control: varying quality code, 5pm code oops’s- synchronising code libraries: everyone for themselves • Developers cannot easily see how to change if they are too busy fighting fires • Sometimes too close to issues, cannot see that change is needed, or that change is even possible • Managers push for the quick result, usually less tests

13. The Fix: Continuous Integration • Automate everything you can:- testing, builds, and deployment where possible • Many ways to do this from DIY, open source, to commercial packages. • Any improvement will help • Find the easiest or cheapest, and start there • We have adopted JetBrains TeamCity (free version) • TeamCity has 3 models: free, paid, enterprise • Supports many different build, test and deploy configurations for Java, and .Net

14. TeamCity integration • Integration with just about everything: • CVS, Subversion, ClearCase, GIT, Perforce, TFS, Mercurial, SourceSafe, StarTeam … • Ant, Maven 2, IntelliJ IDEA, Nant, MSBuild … • Email, RSS, Jabber, IDE, Windows Tray … • Eclipse, IntelliJ IDEA, Visual Studio … • Junit, testNG, EMMA, Cobertura … • Rake, NuGet, Powershell, Command Line, FxCop, Gradle …

15. Broken code doesn’t make it into source control any more

16. Pre-tested commits

17. Were Next? • Open source our work in the Preactor API to gain community involvement in growing the core code • Currently publishing on Codeplex using GIT(will be public within the next 30 days)see http://pom.codeplex.com • Currently using TeamCity’s internal NuGet server internally(handy for internal-only library builds) • Soon to be added– public NuGet- link Codeplex + in house GIT + TeamCity + NuGet