Hacker News Reader

Comment by gnud | Hacker News Reader

The last full system I delivered was created using a sort of waterfall/agile hybrid. We worked from a backlog, in short-ish sprints, but nothing was put into production until a certain milestone was reached, after multiple sprints.

We were replacing an existing, legacy system, and even though we switched over "piece by piece", each module of the old system was at least 10-12 sprints. And the end-users couldn't do a meaningful test of their normal tasks until most of each module was implemented.

How to teams who manage to work more "agile" do this sort of thing?

View on HN

This seams a pretty reasonable approach to solve this problem. The only improvement I could think of is to "mirror" the data or API calls to the new system so it gets battle-tested earlier, but that only works for backend systems.

We did that for parts of the system, but that mirroring also needed to be implemented and tested. So most modules we straight out replaced once the new versions were done.

That only works with similar architectures. I've been involved with converting mainframe batch systems to service-oriented architectures on distributed systems, and that sort of mirroring does not work at all.

It's fine for prying microservices loose from monoliths for relatively modern REST api systems, tho. Big problems I see there are that the problem often isn't the code, but rather the api itself that's a mess, and evolving the api breaks client code which you may or may not control.

> converting mainframe batch systems [...], and that sort of mirroring does not work at all.

Interesting, what are the problems you encounter if you try that?

The problem is that you're building a new system to completely replace an existing system, and the existing system is tightly integrated in a way that makes piecemeal change difficult to impossible. And the new system isn't just a refactoring for bad code - it's a redesign in the name of new functionality.

In this particular case, it was a banking system that worked largely by nightly batch jobs. Data queued up during the day was processed at night. Job A triggers Job B, which Triggers Job C; etc. What we wanted was to change those batched transactions into individual transactions that could be processed in synchronous quasi-realtime.

With reconciliation happening near the end of the batch processing, how do you do that?

And mind you, this system moved more money every day than the GDP of many countries. Failure was NOT an option. Not if you don't want to roast the entire US economy. So the consequences of error were truly terrifying.

Consider what it was like when web browsers used to be rolled out every 6 months or so. When Google (I believe) started to rollout virtually weekly (or even daily sometimes) updates, there was a bit of a riot from enterprise users. "How will we verify that we can roll out the new browser when you update it so frequently", they said. And then Mozilla followed suit. Eventually people realised that if you roll out an update nearly every day, each update only has a tiny modification in it. You almost never need to validate it. Even if it goes wrong, as long as you can roll back to yesterday's build, you are OK.

Having said that, I still think there are projects for which it is best to do it the way you say. I've certainly had a lot of success with that approach as well. As others have said, if it ain't broke, don't fix it.

> Even if it goes wrong, as long as you can roll back to yesterday's build, you are OK.

Except that when the versions are coming out too quickly, you don't know to which version you should roll back, because it took longer to encounter the problem (let alone pinpoint its origin) than the time between releases and several or even many occurred meanwhile.

Why were you migrating the system? What kind of impact were you trying to deliver? Was there a way of giving that impact incrementally, rather than delivering it all at the end? When whoever’s paying for the project asks how it’s going, what do they care about, and how can you measure progress towards those things?

There’s no silver bullet. Small a agile is really a way of thinking as a team. Unfortunately, the big guys often sell it as Big A Agile with a list of processes you need to follow so you can avoid that thinking.

The main "impact" was allowing the users to update past windows 7, once they got off their old, legacy, no-longer-updated system :)

Of course, at the same time we tried to improve certain workflows and clean up various parts. But mostly, this was a straight replacement.

Putting things into production isn't a requirement of agile, it just should be potentially shippable.

It’s never easy :) In this case though I would try to explore ways to deliver meaningful work to the customer more quickly. Without that quick feedback loop the entire premise of “agile” is meaningless (at that point it's basically just a way to organize your todo list).

Why worry about how do it more “agile”? You have a reasonable approach that works. Celebrate that.

Reply on news.ycombinator.com