Keynote speakers drop the mic at Simply Business's third internal tech conference

Learning is one of our core values at Simply Business. So the technology team was excited to invite experts in their field to inspire our software engineers to learn about the challenging aspects of Agile software development, domain-driven design and application security, at its third internal tech conference in 2021.

Why hold an internal tech conference?

Our internal SB Tech Conference provides an invaluable opportunity for our 120+ strong software engineering team to come together to deepen their knowledge, share experiences and be inspired by technology experts. Run by engineers for engineers, in collaboration with our Training and Conferences community of practice, the SB Tech Conference came about as a way of levelling the playing field for everyone in our technology department to be able to attend technology events.

"Although our teams regularly attend external conferences, we realised that often only a handful of people were able to attend. We wanted to open up specialist technical learning to everyone in Simply Business tech, instead of relying on those attending external events to share that knowledge with their colleagues. By organising our own internal tech conference, we've been able to give everyone in tech the opportunity to deepen their knowledge, share their technical challenges and network with specialist speakers".

Emily Harris, TechOps Lead, Training and Conferences community of practice

Highlights from this year's SB Tech Conference

The Simply Business Tech Conference 2021 was a big hit with our UK and US technologists. This year's conference organisers (TechOps team Emily Harris and Emma Hurndell, Senior Cyber Security Analyst Laura Blackwell and Staff Engineer Hemal Varambhia) lined up keynote speakers to talk to us about:

• Agile in 2021: What’s changed in 20 years
• Domain-driven design: A beacon for your legacy software
• Security in an Agile environment

Here's a roundup of some of the takeaways from the conference talks.

Agile in 2021: What's changed in 20 years?

Tim MacKinnon, Agile Consultant and technologist, talked to our engineers at Simply Business about what's changed in Agile over the last 20 years.

Practices such as pair programming, testing, retrospectives and continuous builds have been around for decades. But are these practices an Agile fairy tale? It sounds simple, but Agile is not magic. Software development is hard. It's not just about managing changing requirements and working with the business, it's also about humanity and teams, and understanding that people make mistakes.

In software engineering there is often a focus on the negative; software engineers don't talk enough about successes. The key is to take baby steps and take responsibility for what you're doing. Practices such as Agile and XP are all inter-related; they're about striving for more rather than dropping the bar so that everyone can jump it.

In his talk, Tim emphasised the importance of sharing a common vision for architecture. We may think we're talking about the same thing but in reality we may not be, so it's important to look down the road and understand how that road will change. It's important to share a North Star vision for a project. Drawing sketches and having visual metaphors, storyboards and visual artifacts go a long way in getting joined-up thinking.

Simplicity can often be undervalued in tech. Domain-driven design advocates creating an ubiquitous language and simple design - doing the simplest thing that could possibly work. Tim reminded us that CRC cards are an underused art that can help teams understand the entities in a system and how they communicate with each other. Acting out the system using CRC cards can help to simplify solutions.

Tim stressed that all practices are important and to focus on how to do something better or in a different way rather than throwing it out.

Some of these practices might include:

• Using the '5 Whys' technique to get to the root cause of every error.
• Writing tests for features.
• Refactoring as a routine. Like maintaining simple hygiene in a restaurant, there's always tidying up to do.
• Pair programming to improve quality, pulling the load together and having fun in achieving.
• Short releases and small iterations.
• Planning and ensuring cards have a good title. Iteration planning and estimations can be kept lightweight to understand the tradeoffs in what to do over what to drop.
• Burndown charts.

Concluding, Agile still delivers in 2021. Balancing business and technical decisions, managing risk, using people-oriented processes and most of all making things human is important. It's thinking about how to hit a ball down a golf course, then dreaming about where you're going and creating a positive core.

Domain-driven design: A beacon for legacy software

It's not uncommon for software engineers to favour working on new code rather than legacy apps. Julie Lerman, a keynote speaker in domain-driven design, architecture and evolving legacy code, took Simply Business engineers through some ways to put this into perspective and how to devise a strategy for the future.

Programming Entity Framework by Julie Lerman.

From her experience in speaking at international conferences, Julie raised an interesting point that it's normal for many engineers to be working on code that's ten or more years old, but that legacy code exists because it's still important to the business.

Many industries are still being run on very old software that still works, so it's not easy for companies to think of getting rid of it or taking up the investment to replace it. There's also the risk that replacing the legacy system will break something.

So how can companies who want to move away from legacy software approach the transition to a new system?

• A good place to start is to create a strategy for tackling technical debt:
• Investing in reducing technical debt in the legacy system, in the areas that hinder maintenance or development of new features. Reducing the number of bugs and refactoring the code that engineers have to work with.
• Assessing where the tech debt is; which areas of code are really causing problems.
• Going after bugs. Using a day a week to fix bugs in tech debt.
• Refactoring only the areas that engineers need to maintain. It doesn't make sense to refactor code if it doesn't affect what you need to be doing.

When tackling software complexity, applying the principles of domain-driven design provides a strategy for breaking big complex problems into smaller ones. It's important to understand the domain and its behaviours through deep engagement with domain experts to learn about the business. Julie advised that there is no need to be an expert in all aspects of domain-driven design straight away:

• Start with bounded contexts - an often misunderstood domain modelling term introduced by Eric Evans, is explained in Domain Driven Design Europe (YouTube). Bounded contexts can be used to understand how to transform legacy software.
• Use mind maps to collaborate with people who have knowledge in areas that are not well-understood, to bring focus and clarity.

To help identify bounded contexts, event storming is a useful brainstorming technique. Start by writing down what you know about the system, then order and group them. Identify the events that are transitional - these can identify new boundaries and bounded contexts.

Julie concluded that the key to working with legacy code is to honour it, improve it and then transform it.

Security in an Agile environment

The closing talk at the SB Tech Conference was on application security by Scott Helme, a security researcher and an international speaker who delivers training on hacking and encryption for software professionals.

Scott Helme is the founder of Report URI and Security Headers.

Scott shared his wealth of security expertise with Simply Business engineers and gave some tips on navigating the numerous security tools available. He explained the need to shift security left and train developers, so that security is not a tick box at the end of the development pipeline.

Scott spoke with us about some of his earlier security research such as the EE Brightbox router vulnerability he discovered - both part 1 and part 2 - and the struggles he has had reporting security vulnerabilities to organisations in the past.

These are some of the tools that were top of the list for website security testing:

• Security headers (www.securityheaders.com) - a website scanning tool that analyses raw HTTPS response headers and scores applications based on how many security-based HTTP response headers the site issues.
• The Hack Yourself First website (www.hack-yourself-first.com) is a great place to start testing for SQL injection. Used to test for cross-site scripting, scripts that run malware, as well as scripts that are reflected back in the web page.
• ZAP's web app scanner (www.zaproxy.org) is open source and integrates with Jenkins.
• Burp on MacOs (www.portswigger.net/burp) is aimed at security professionals and scans for common vulnerabilities, proxy traffic and inspection of requests and responses. SSL labs (www.ssllabs.com/ssltest) is a free tool that lets you take a score of encryption on a site to see what's secure.
• Testing TLS/SSL encryption tool testssl.h (https://testssl.sh) runs against internal endpoints and gives a score for encryption.
• Charles proxy (www.charlesproxy.com) for MacOs gives developers a view of all HTTP and SSL traffic between their machine and the Internet. Telerik's Fiddler (www.telerik.com/fiddler) provides similar features for debugging and break encryption on Windows applications.

Tooling can go a long way towards narrowing down issues further down the line, but Scott was keen to point out that there is always a need for pen testing by someone with the skills to be able to break the system.

Tips for organising an internal tech conference

This was our third internal tech conference in recent years. Now that our tech team has expanded in different geographies, we held the conference sessions over Zoom on two consecutive afternoons, so that teams in different countries and time zones would be able to attend.

Running an internal tech conference takes some preparation. If you're thinking of organising your own internal tech conference, here are some things we've learned along the way:

• Get buy-in from the senior management team to dedicate a half-day or more to hold the conference.
• Do some research on what subjects your tech team would want to learn more about. Consider setting up a community of practice for interested people to drive internal learning. At Simply Business, our Training and Conferences community of practice is a mix of people from different disciplines who meet monthly to come up with technical learning initiatives, which is focused only on tech. As well as looking after the Simply Business Tech Conference, they help to focus training and conferences on skills gaps and strategic learning that would benefit the majority of tech.
• Get as much support as you can early on in organising, promoting and running your event.
• Set aside some dates and plan well in advance. If your teams are global, choose time zones that work for those locations so that as many people can attend as possible. Different geographies have different country holidays, which may be another factor to consider.
• Find speakers on subjects that your tech team would find valuable and book them in to speak at your event. Confirm, confirm, confirm.
• Communicate the dates for your internal tech conference and book them in your company calendar.
• Promote the conference frequently and remind people your event is coming up. Consider using prizes as incentives and to interact with the audience.

As the conference date approaches, all that remains is ensure it runs smoothly:

• Prepare the ground rules. Ask speakers if they want to take questions at the start, as they go or at the end. We chose to use a Q&A session at the end of each session to keep the schedule on time.
• Decide whether you'll record the talks to share with people who are unable to attend. Ask the speakers if they are happy to be recorded.
• Choose a moderator who can introduce the speakers, field questions and keep an eye on online chats for questions being asked during the talk. The moderator can pick up on questions in the Q&A.
• Get feedback from those who attended, to get insights into whether the talks and subject matter were pitched at the right level for the audience. Use this feedback for future conferences.

We hope this inspires you to run your own tech conference!