Software development and a two-decade customer

To earn my bachelor's degree in Telecommunication Technology — Communication Networks, I had to complete a supervised internship.

One professor needed an intern for one semester to help him with his PhD research. He was working on a cellphone provider solution for remote areas to propose an economically viable project. One key component was selecting the cell tower controller with the optimal number of channels. Fewer channels reduce costs but decrease the quality of service (QoS), specifically the grade of service (GoS).

My job was to create a static webpage using a Java Applet to calculate the GoS and plot the graphs for probability of blocking, like this one:

The challenge was to break the formula into the right pieces to avoid precision loss due to the high number of channels. Back in those days, Java Applet browser implementations didn't have arbitrary-precision libraries, and all calculations had to use 32-bit numbers. No backend calculations at all. It was a simple HTML file and a Java Applet running offline in the field, while the professor was testing antenna setups in rural areas.

For the nerds reading this: take a look how it was to program using Ancient Java in this Medium article (not mine): How does it feel to code Java 1.0 in 2024?

After that, a chemistry professor invited me to interview for an internship with a regional board of professionals. The chairman and the new board members were tasked with modernizing the administration and improving the services provided to the associated professionals.

During the interview, the chairman was very clear: they needed one person to create a revenue collection system from scratch. There was no server infrastructure, no system, and no I.T. professional to pair with. They had computers, but they were used only for a text editor, a spreadsheet, and e-mail. It was August; the new system had to be ready by the end of November, and they had a budget for just one intern!

Challenge accepted!

I used the best computer they had as a local server for the database (MySQL) and the web application (Microsoft IIS + PHP at that time). Java was not an option because it would require a better server, and there was no budget for that.

The system was delivered on time, and invoices were automated and sent by the end of that year. The revenue increased, and I was granted a part-time job before finishing college to take them to the next level of I.T. systems. It lasted one decade, and I will talk about that in another post.

A few months later, the board chairman introduced me to someone who was asking for a customized system. The system objective was to keep registries of legal auctions and produce legal documents. There were only a few users, and the system was used for a few days each month. But it could not lose any information.

The first version was prepared to run on a Windows desktop computer running Apache+PHP+MySQL before WAMP was available. To preserve the data, the system included a built-in backup feature that created a single ZIP file, which was stored on thumb drives.

The architecture evolved through the years; the system moved from desktop to a laptop, and then to the cloud. New security layers and backend updates, database improvements, and new JavaScript versions required frontend adjustments. And very rare business rule changes over the years.

Now, more than twenty years later, I can assure you that NOT using a framework was a wise decision! Pure PHP in the backend, pure HTML+CSS+JavaScript for the frontend, and a database with no stored procedures. It is easy to update each component and to keep everything up to date.

The system is still running, serving users well, with no security or data loss incidents and very low cloud costs (less than a restaurant dinner per month). Solid principles, coupled with the right-size architecture, kept this twenty-year-old system alive.

Later in my career, I learned fancy names for some of the things I did during those early career times: BPMN, product design, user interviews, prototyping, payment automation, business continuity plan, …

For all that, now we have better names, better processes, and better tools, but the questions remain the same: Are we building the right thing? Are we building it right?

If you missed the beginning of this series, here is the link: How I got into the tech industry

The promise is to keep my posts simple enough for non-tech people and include enough technical details to please the nerds like me.

How is it going? Tell me in a comment.