About
I'm a Senior D365 Finance & Operations Developer and Technical Consultant at Delaware UK & Ireland, based in Manchester.
I started out in October 2007 as a trainee programmer at Mahindra Satyam in Chennai, expecting to build websites in ASP.NET. Within a year I'd been moved to the Microsoft Business Solutions team and handed Axapta 4.0, which I'd never heard of. Eighteen years later I'm still working in the same product line — it's just called Dynamics 365 now, and I've followed it through every version in between: 4.0, 5.0, 2009, 2012 R3, and D365 F&SCM.
That continuity turns out to be unusually useful. When someone asks why a particular piece of posting logic behaves oddly in F&SCM, there's a reasonable chance I worked on the AX 2012 version of it, and a decent chance I remember why it was written that way. Most of the upgrade projects I've led have been less about writing new code and more about understanding a decade of decisions well enough to know which ones to keep.
What I actually do
Most of my work sits in three places. Development — X++ and C#.NET, extensions, custom entities, security policies.Integration — Azure Logic Apps, Function Apps, API Management, the Data Management Framework, and the long tail of SFTP, blob storage and legacy systems that every real ERP estate is connected to. Reporting — SSRS, Docentric, Power BI and Electronic Reporting, including the model and field mappings that make ER do what the finance team actually asked for.
At Annata, where I spent nearly five years, I led three full-lifecycle D365 F&SCM implementations, four integration projects and an Electronic Reporting project, and worked on the upgrade path from AX 2012 R3. Before that I spent five years at HSO, first in managed services support — which is the fastest way I know to learn what breaks in production — and then in the optimisation projects team, taking on custom work across retail, rental, manufacturing and distribution.
What I've come to care about
Integration failures should be loud. The worst bugs I've dealt with weren't the ones that threw an error. They were the recurring imports that quietly skipped rows for three months and surfaced at year end. Designing for visible failure costs a little up front and saves an enormous amount later.
Upgrade-safe code is a discipline, not a preference.Anything that breaks on every platform update becomes a tax the client pays forever, usually long after you've left the project.
TODO — a third conviction. Pick one you can defend in an interview: something you've genuinely changed your mind about, or a hill you'd die on. This is the most memorable paragraph on the page, and it's worth taking a while over.
Before Dynamics, and alongside it
My MSc in Advanced Software Engineering at the University of Sheffield included a year at Genesys Solutions, the university's student-run software company, building and testing Ruby on Rails applications with Cucumber and RSpec. It's a long way from X++, but test-driven development and proper automated testing are habits I picked up there and have kept.
I've also coached at Rails Girls Manchester and mentored at Django Girls with CodeNation — both worth doing, and both a good reminder of how much of what we know is assumed rather than explained.
Outside work
TODO. Two or three sentences — whatever you'd actually mention to a new colleague over coffee. You also run a knowledge base with Andrew atkb.hills-family.uk, which is worth a mention: it shows you write and share by default.