Picture a typical developer: the bearded grump who works by the light of a computer screen. But you won't find that stereotype at many companies – and certainly not at Akuiteo. Being a “dev” is a demanding and structured job that relies on teamwork. Read on to find out about the ins and outs of a developer’s world. It's really not as strange as it seems!
Developing and maintaining code: a developer’s two main jobs
Every day Akuiteo’s development team works on ERP developments, creating new features and improving the tool’s stability. Team members also hunt down any software regressions that get spotted when a feature stops working, for example, after a new version is released.
What's more, developers take turns maintaining the code, one developer each day of the week. On their allotted day, the developers will follow up customer requests and fix bugs.
- They log the requests forwarded to them by the support team (the version and database being used, business sector and specific development).
- They reproduce the problem in the client’s environment.
- They analyse the problem and identify the root.
- They fix the bug.
- They check if there is a bug in the last stable version of the software and, if so, fix the bug.
- They update the development version.
- They carry out unit testing to eliminate the technical debt.
Unit testing: a safety net for code
We can create new unit tests during maintenance or refactoring. Refactoring is when we simplify the code while checking that it still has the same result – you may hear us talking about reducing the technical debt. We work on pieces of code that we know inside out, refactoring different bits as we go.
During every “clean-up”, Akuiteo’s developers try to create tests that incrementally improve the ERP solution. So a unit test is code that tests code. For example, once a day or straight after we release a new version of an app, we automatically run all of the unit tests.
To date, Akuiteo has set up thousands of unit tests, on top of using a code quality analysis tool (SONAR), running large-scale projects to reduce technical debt and following coding rules based on the development approach outlined by Robert Cecil Martin in Clean Code. Besides supporting code reviews (which is when a developer systematically examines the source of a piece of software they didn’t originally code), unit tests fulfil several objectives:
- For maintenance, they ensure that once you’ve fixed a bug, it won’t ever come back, which slashes the number of problems reported in the long term.
- For development, they help preserve knowledge of the code, create a safeguard for future developments and fixes, identify critical code and ringfence it for better protection.
- Last, these tests help with functional requirements: they show what the developer’s goal was when coding the feature.
Agile software development at Akuiteo
Day to day, the development team works using agile methods, which date back to 2001 when 17 software developers established the goals for this way of working; they wanted to rethink the software development processes.
What does an agile approach achieve? We can quickly change and tweak any issue that comes up before we deliver the final product. To do this, we encourage clients and consultants to work together throughout the development phase, with phased deliveries, to ensure that the end product fully suits users’ needs.
Sprints
Every fortnight, the development team gets together to discuss the deliverables for the next sprint. In agile software development, a sprint, also known as an iteration, is a relatively short fixed period of time (a few weeks) during which specific developments have to be completed. At Akuiteo, the number of developments is worked out with the development teams.
During meetings to launch the sprint, the whole team gets up to speed with all of the developments requested. Skills transfer is strongly encouraged so development doesn’t drain critical resources, which we need to move forward. For example, a specialist in time-management features will also be encouraged to work on VAT.
Besides increasing developers’ visibility, this way of working means that we won’t be working on a constant stream of new developments. So a sprint is effectively a contract: for the next two weeks, you set out what you’re going to do. And if you complete the contract earlier than expected, all the better! However, the team won't take on any additional requests that aren’t related to the current sprint.
You can use any time you save to work on developing in-house tools and refactoring, in line with Akuiteo’s quality-driven approach.
Quality team
Two people are responsible for approving every development. The result is super fast feedback on everything, which means any problems are nipped in the bud.
The quality team brings together developers and the person who wrote the functional specifications. Ideally, before any complicated development, there will be a meeting with the person who requested it and possibly the lead developer (or “lead dev”) to nail down what’s required and guarantee that the development goes ahead as requested.
The development team regularly presents developments to in-house consultants or directly to project managers or clients, with the support of the quality team.
Daily stand-up meetings and monthly meetings
Besides daily stand-up meetings that improve communication within the team and highlight any problems, developers also get together for monthly meetings. These meetings are all about feedback: developments that haven’t turned out as expected, working methodologies that could be improved or tested, and ideas about how to develop the intranet, for example.
Read also: The Agility of a Business is Down to its ERP Software.
Just like project managers, developers are not infallible. So refactoring, unit testing, regular meetings and a specific quality team all act as safety nets to ensure that our ERP solution has high-quality developments. Akuiteo’s development team has a simple aim: to streamline maintenance day by day, and improve software performance line by line and unit test by unit test.