Seriously, no posts since February!!
Okay, so not a lot has happened, life has continued and I have got older. My role in my $dayjob has evolved once more and the team I am the “Development Team Leader” has grown by two developers.
I have dropped out of the CPAN challenge, it was hard. And more to the point my time has been severely limited so working on random Perl modules dropped of the priority list to the point I stopped participating.
Code wise I have been busy though. The $dayjob has had me working on a wide variety of areas and working with others on thier parts on a daily basis also. Most recently, I worked on an entirely new internal web application and a port of an older part of the public site.
The internal app was good and challenging. The scope was rather large and after some investigation, discussion and agreement I was able to agree with the key “stakeholders” (alarm, alarm, business speak) to limit the scope to a more basic version of what was desired; but with a greatly reduced development time (weeks not months).
As a new app, it meant not having to navigate legacy code. Which is nice. However, there was legacy data and a legacy app that needed to be interfaced with and the new app compared against.
I was able to work in a pair for much of the development; and we were able to quickly build a sync script that would populate our new system with the existing data each night. Meaning that when we were showing the screens and functions to others it had real data rather than bogus data.
It also meant that when people tried things in the new system we were not worried they would affect live data. Each night the system would wipe itself clean again. This meant we were able to build in small increments, deploy immediately and allow people to test features as we went along; rather than waiting till the end.
It has been a good project and it was also well tested during development both manually by guinea pig users and by unit tests, integration tests and end to end tests.
The plus side of all the up front testing has been that as “bugs” have been reported during roll out to all staff; we have not found any actual coding bugs. Plenty of scoping problems and misunderstanding on features both on user and development side. But not actual code bugs.
I also paired with another member of the team, on a external facing port of a part of the business application. Specifically migrating some very old and crufty legacy code to a Plack based app and moving some of the embedded business logic out of the controllers and down into services.
This has been a long project, with the initial work taking far longer than expected. In part as we built the framework upon which all future modernisation of codebase from oldest legacy will take place.
I have likened the task as taking a huge giant sized bowl of spaghetti, and initially putting the same spaghetti in several smaller bowls. Then taking the spaghetti from those bowls and putting them in small bowls again. Then taking the spaghetti from those bowls out, straightening it, cleaning it and putting it in a new nicer bowl. Then repeating across all the bowls. Then merging across some bowls so we have a nice tidy collection of a few bowls of better spaghetti and some nice straight spaghetti in places.
It’s not a great description I know; but it does describe what working on a legacy code base can be like sometimes. Compared to the other recent brand new app work; it is really challenging.
The hard bit with working with legacy code (ok there are lots of hard parts) is that you have to make decisions about how much to tackle at one time and balance that against the benefits in terms of delivering not only a cleaner codebase but also some additional functionality for users. I personally don’t see much point in modernising a codebase if some actual business value is provided also. It’s a trade off. I want some time to clean the code, you want some features. So lets agree to spend a sprint delivering one of your features and part of the clean up. Then in next sprint I get to clean up more code and you get another feature.
The hard bit is getting that balance right when old code always has hidden complexity that takes longer than you expect.
But now the first few sprints of work are done and this area gets left alone for a while; I am happy that the most of the top layers are better than they were and we even managed to get some data changes made that will help in the next tranche of work.
Beyond direct code projects, our team organised and held a javascript evening in the office. This was to address the feeling within the team (as expressed in retrospectives) that the teams javascript could do with some work (we have two junior developers as well as two experienced and two senior).
So we all stayed one evening and ordered in Pizza.
The evening workshop took the form of a bit of a chat/talk by me and the IT director and others. Then we as a group picked an exercise from the the excellent http://cyberdojo.org site.
Then we broke out into trios and worked through the challenge.
After 30 minutes we came back together and talked through each of teh teams results. Code was reviewed as was the approach and methodology taken. Cyber-dojo has built in TDD tools. You can actually watch all the groups red/green states on a timeline.
It was interesting to see how each of the teams interacted and how the personalities and styles of the individuals affected the development cycles.
We repeated the process on another challenge with different trios; that too was worthwhile.
Beyond this, I have done a little javascript server side hacking with node, request and cherio. I also did some updates on my www.judowrl.com javascript single page app.
I really think it’s important to keep learning and challenging yourself; so the past few months although stressful have been good for me.
Anyway… I hope to write more regularly as the team settles into life with two more people.
Categories: Uncategorized
