In my previous post - The case of the local software developer - I asked for your stories. That's mine.
It will be about my first job position at the bank. I joined the IT team as a support guy because the team was small, summertime was coming, and in the last quarter of this year, office movement was scheduled. Printers, cables, hardware, office applications - that was my garden.
But in the meantime, I was talking with a guy from the treasury department, who had some troubles with his spreadsheet, full of smart integrations designed for getting things done faster. It was not the first occurrence, but the first significant one, when I saw "serious" applications - bought for millions, developed by thousands - glued by a "primitive" spreadsheet to work as expected.
I took this spreadsheet to the desk, make many improvements according to software craftsmanship - which was completely unknown to the author - and because it was effective, probably that was my ticket to the long and pleasant journey of the local software developer in the bank.
During the next nine years, I designed and implemented tens of applications, for exactly every department of the bank. Treasury, marketing, accounting, internal audit, security office, customer service, back office, credit & risk analysis, general services, our local IT of course, and even board management. My last works were related to the merger of our bank with another: my locally developed applications supported the merging of CRM systems, general ledgers, internet banking, and data warehouses.
Reaching the end of my first job in the bank, I was full of reflections on how to build that kind of stuff. And when I was fired, while waiting for a new job, which took me four months, I started a pet project to collect all of the ideas and solutions into an integrated framework.
I thought it will be easy, but it wasn't, and it still isn't.
Since this time I made more than one hundred approaches and prototypes. With shorter and longer feature lists. With different main languages and engines - VBA of course, PHP, Node.js, SQL (yes, I know, I know...), and ASP.NET. Different frameworks provided CRUD and full web application generators, scaffolders, and templates. On-premise and cloud. Monoliths and microservices on microfrontends. Including the full development cycle, with issue management, and reduced to installers only.
Let's skip the rest of the paths, less or more blind.
If an architect from DDD school could classify most of them, probably they will be named Big Ball of Mud, although I was pretty sure that it is made with care and competence.
Last year I wrote the manifesto on LinkedIn, which I called Devshire Manifesto - what is a manifesto without a good and proud name? - to take out from the shade and expose local software development, to define and find some answers for obstacles that local software developers meet in their everyday work. (The manifesto is currently written in Polish, there is no translation, I am working on it, and probably it will be published here, on DEV, in the next post.)
This was my first attempt to find help from other local software developers to extract and address some. I know many local software developers. Most of them, asked for an opinion, agreed with me, that there is something to do, but it is not clear what exactly, when and what is a surface of economically important support.
Because I know - we know? - that this help is not required. We can make the next local application as usual, without dedicated discipline, productivity tools, and frameworks.
What's more, some of the prominent players are working on solutions for more general The Shadow IT problem. From the economical point of view, no specific approach is REQUIRED - maybe?
But maybe no. Maybe we can - or we should? - do it better, smarter, introducing software craftmanship to this programming niche.
What do you think?
Top comments (0)