DEV Community: Gerard Jaryczewski

How to define local software development?

Gerard Jaryczewski — Sat, 02 Jul 2022 13:06:28 +0000

Besides professional areas of interest in programming, I am looking for a better approach to local software development in my free time. "What do you mean saying: local software development?", you can ask.

It's a great question. I asked many folks and forums, whether this topic is real or imagined by me only? Maybe there is no such specific context? But before I lost interest, I will try again, in other words:

I recognize a specific context of programming, when:

an organization has a need of some application - a need which is hidden or published, nevermind - but has not enough resources or no required will to design it in a "canonical way" (by public order, an internal request to local IT, etc.),
and there is an employee - a programmer, an administrator, a business employee with entry-level experience in coding, nevermind - who is ready to get this task and design the application using available tools (usually a spreadsheet with macros, a database with form designer, etc.),
and as a result, this application becomes part of so-called shadow IT, a growing and usually uncontrolled collection of tools, which bypasses existing "professional" systems, designed by software houses or installed by IT from public sources,
usually developed by copy-pasting, without a coding standard, without environments, with the manual delivery procedure (if that procedure exists at all), with poor or no documentation, out of control in emergency plans, without regular maintenance procedures, etc.

This specific context I called the local software development.

There are so many exciting consequences of this definition, so many built-in troubles... We'll look at some practical approaches in the next posts.

My local software developer story

Gerard Jaryczewski — Fri, 27 May 2022 20:38:04 +0000

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?

The case of the local software developer

Gerard Jaryczewski — Sat, 14 May 2022 22:19:14 +0000

So it is about local software developers.

You can consider "the local software" as the core problem, or you can see "the local developer" behind it. As Jack Sparrow said, the problem is not the problem, the problem is your attitude about the problem.

Fortunately, these two attitudes are good enough, are relevant, and are complementary to my question to all of you.

Let's look at the example. Let's assume you are a dealer in a bank, or you are a raw IT specialist, working for the dealer. And you need to make some calculations not available at all in company IT systems, or available too late, or constantly incoming with some bugs and gaps.

If you are smart - and dealers are usually pretty smart, I know many smart dealers, some are smarter than me - you can do it by yourself.

Of course, there is usually a possibility to send a request to the local IT and order an application, but... there are many reasons why it could not be possible. The reason is unimportant.

Let's move forward to the next episode, to keep it short: we make a decision that we do it in Excel and VBA. Looks familiar? No doubt. We can even formulate a rule:

In every non-trivial business IT ecosystem, at least one Excel spreadsheet is an important, non-easily removable part of the most critical core process.

I do not know, whether someone already formulated this rule, but I am pretty sure that I cannot be the first.

Go to the next season: we make a decision about a next application of this kind, and a next, and a next...

The applications have some parts in common, especially these parts of code with holy curtains of comments, saying nothing, or saying something incomprehensible, including declarations of a better future (TODO), with warnings about dangerous spells within (XXX and HACK).

We were there, all of us, weren't we? Maybe we forget, but our comments do not forget about us.

Less or more similar, generally these applications are milestones of our education, at least in VBA, sometimes in programming at all. So every one of these pieces is working in another manner and requires a different approach to maintenance.

Sometimes we have a bigger twist in this serial: we build the one omnibus application, which rules all of the applications.

Yeah, we know this story very, very well, at least some of us.

So my question is: can we proceed with that case in another way? A smarter way? The programmer's way?

Maybe not, because this local software developer case is often the usual software developer case. So maybe this is a bigger problem, a paradigm problem.

But maybe it is possible?

I have a general concept with many details, but now I am pretty interested in gathering opinions. I have started with a similar question at some world-known communities:

In brief, I have found some nice and interesting comments by programmers writing about their own professional career stories, but the feedback was rather poor. Maybe it is my fault, I have made at least one mistake, asking for opinions at Stack Overflow - do not do this at home, I earned a ban although the goal was precisely defined at the beginning.

To the shore! What do you think, is it possible to build local software in a better way? Or, at least, what is your local software developer's story?

PS It was my first post at dev.to, thank you very much for reading.