Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Using XP practices on
1960s green screen
technology
The system that time forgot

Brian Leach
Nik Silver
Context
How we went…

from this…

…to

this
Wider Context
• Senior management buy-in

It’s not legacy, it’s a

• More team-working

heritage system.

Knowledge silos ...
The technology
What is It?

The
What is
UniVerse?

Original

No SQL
Database
1960s
1980s

MySQL
NOSQL

1970s

SYBASE
SQL SERVER
UNIVERSE

UNIX
REALITY
SQL
ORACLE

GIM-1
NELSON
PICK

A History Lesson
...
UniVerse BASIC
The UniVerse Business Language

Embedded

Procedural
Runtime Loaded

Data centric
Concurrent
Business focused
No encapsula...
Do you have global
variables ?

Hell, yes
Challenges from the UniVerse Environment

The database

is NOT a
dependency

Bad Code
is platform
independent
TDD
What engineers were seeing
TDD + FitNesse training for
Java/.NET
Sometimes learning Eclipse,
and Java, too

There was a ba...
The Challenge – In Numbers

•40,000+ concurrent connections

Over 700 lines
of code added
every working
day for 25 years

...
Lest we Forget

This application
has powered a
business for
over 25 years
to an annual
turnover of
5 billion pounds
What we did
• Wrote our own framework


Created own refactoring catalogue



Started UniVerse-specific TDD training

• R...
Some Lessons
Learned ..

and shared..

Units are different in UniVerse.

Via refactoring catalogue

The database is under ...
Areas of resistance
“It’s a waste of time”
“It takes too long”
“We’re going to throw it away anyway”
“We can’t spend time ...
We had to name the framework
We had to name the framework
Git
Experiences Introducing git for UniVerse
• February 2013:


TFS introduced for source control



Very slow



File-driv...
Git Anguish
• Change of workflow


Whole codebase snapshots



File locking

• Inclination to want all problems are solv...
Git anguish resolutions… and disappointment
• Regular discussions and
steering

• Some people still use
old editors

• Adj...
CI Pipeline
CI Pipeline

Local
Devs

gitlab

listener

Commit
Log

QA
Systems
Packager
System

Release
Area

CI
(pull,make,test,sync)
Consistent reliable environments
• Chaining to/calling fatal errors or stop
• Calls which kill the CI process
• Lots of as...
CI Surprises
• Needed to clarify the development process
• Engagement around non-compiling code
• Reaction to global CI em...
Wrap-up
Achievements
• Human rewards…
• Engineers feel part of the modern world


Hackathon



Coding katas

• Feel invested-in
...
Where Next ?
• Improve CI process
• Extend packaging
• BDD
• And on and on…
Sep
Jun
Mar
Dec
Jun Sep

1996
1987

2013
2012

Timeline

Switch-over to git + CI
Start git training for UniVerse
Start bui...
Using XP practices on 1960s green screen technology
Using XP practices on 1960s green screen technology
Using XP practices on 1960s green screen technology
Using XP practices on 1960s green screen technology
Using XP practices on 1960s green screen technology
Upcoming SlideShare
Loading in …5
×

Using XP practices on 1960s green screen technology

793 views

Published on

By Brian Leach and Nik Silver. First presented at London XPDay 2013, 25 Nov 2013.

Synopsis: Travis Perkins has introduced some very modern technologies in the last few years, but half of the 120-strong software engineering team is actively developing in BASIC on its 1960s green screen technology platform. Brian and Nik show how it is possible to introduce XP practices to technology that predates the moon landings, and will discuss lessons learned. They will cover unit testing, source control, and continuous integration, and will touch briefly on future objectives.

Published in: Technology
  • Login to see the comments

  • Be the first to like this

Using XP practices on 1960s green screen technology

  1. 1. Using XP practices on 1960s green screen technology The system that time forgot Brian Leach Nik Silver
  2. 2. Context
  3. 3. How we went… from this… …to this
  4. 4. Wider Context • Senior management buy-in It’s not legacy, it’s a • More team-working heritage system. Knowledge silos and functional teams. Pairing, independent teams, breaking down of knowledge silos, closer involvement of stakeholders.
  5. 5. The technology
  6. 6. What is It? The What is UniVerse? Original No SQL Database
  7. 7. 1960s 1980s MySQL NOSQL 1970s SYBASE SQL SERVER UNIVERSE UNIX REALITY SQL ORACLE GIM-1 NELSON PICK A History Lesson 1990s
  8. 8. UniVerse BASIC
  9. 9. The UniVerse Business Language Embedded Procedural Runtime Loaded Data centric Concurrent Business focused No encapsulation No type-safety No standard tooling
  10. 10. Do you have global variables ? Hell, yes
  11. 11. Challenges from the UniVerse Environment The database is NOT a dependency Bad Code is platform independent
  12. 12. TDD
  13. 13. What engineers were seeing TDD + FitNesse training for Java/.NET Sometimes learning Eclipse, and Java, too There was a basic test “template” With if/then instead of assert Could not see how unit testing applied to them: Procedural code Not designed to be tested Not part of the culture
  14. 14. The Challenge – In Numbers •40,000+ concurrent connections Over 700 lines of code added every working day for 25 years • 4x HP Superdomes • 1 million+ reads/machine/second • 12,000+ programs • 4,644,481 lines of application code • 31% have cyc. complexity > 50 • 12 TB changes every day • 120 software engineers • ... And growing
  15. 15. Lest we Forget This application has powered a business for over 25 years to an annual turnover of 5 billion pounds
  16. 16. What we did • Wrote our own framework  Created own refactoring catalogue  Started UniVerse-specific TDD training • Rewrote the framework  Simpler API  Collaborative effort • Extended the framework  File configuration  Subroutine fakes
  17. 17. Some Lessons Learned .. and shared.. Units are different in UniVerse. Via refactoring catalogue The database is under test Via TDD champions There are limits to breaking down procedural code.  Critically, they drive each other  Starting to inherit tests  Community site for discussion of techniques
  18. 18. Areas of resistance “It’s a waste of time” “It takes too long” “We’re going to throw it away anyway” “We can’t spend time on it if our product owner doesn’t prioritise it” Effective pairing is more difficult with procedural code.
  19. 19. We had to name the framework
  20. 20. We had to name the framework
  21. 21. Git
  22. 22. Experiences Introducing git for UniVerse • February 2013:  TFS introduced for source control  Very slow  File-driven/fragmented in a central repository • April 2013:  CloudShop moved to git (practical and strategic), trigger for similar move for UniVerse • Ambition:  Switch over in June firebreak, but lots of anguish…
  23. 23. Git Anguish • Change of workflow  Whole codebase snapshots  File locking • Inclination to want all problems are solved. “Git is not suitable for UniVerse”
  24. 24. Git anguish resolutions… and disappointment • Regular discussions and steering • Some people still use old editors • Adjusting world view • Difficulties with three way merges • Git training • Adopting better tools • Finally went live in… September
  25. 25. CI Pipeline
  26. 26. CI Pipeline Local Devs gitlab listener Commit Log QA Systems Packager System Release Area CI (pull,make,test,sync)
  27. 27. Consistent reliable environments • Chaining to/calling fatal errors or stop • Calls which kill the CI process • Lots of assumptions about the environment, and continually challenging to ensure it’s clean. • Non-compiling programs
  28. 28. CI Surprises • Needed to clarify the development process • Engagement around non-compiling code • Reaction to global CI email Good results:  Whole codebase compiled for the first time  Real collective ownership  Commits circulated to whole of Engineering as a matter of pride.
  29. 29. Wrap-up
  30. 30. Achievements • Human rewards… • Engineers feel part of the modern world  Hackathon  Coding katas • Feel invested-in • Have more transferable skills • TP held up as an exemplar • “Best Agile Team” award 2013
  31. 31. Where Next ? • Improve CI process • Extend packaging • BDD • And on and on…
  32. 32. Sep Jun Mar Dec Jun Sep 1996 1987 2013 2012 Timeline Switch-over to git + CI Start git training for UniVerse Start building CI pipeline Target for git switch-over (missed) Planning git and CI for UniVerse Started TDD for UniVerse Cloudshop moves to git Source control introduced (TFS) teams start working in step TDD training starts Scrum teams arranged Senior team assembled New CIO arrives Coding .... 1996: Migration to UniVerse 1987: Development starts 1987: Development starts Tech appendix follows…

×