Berg Software rolls high on 30 years of software technology

You know how a dog’s year is about five human years? It’s the same with the software industry: high-speed innovation, combined with exciting client projects, means that 30 years of software development feel like 150. Old? Nope, just experienced and as ready as ever to kick and roll with any tech that comes next.

So, what does experience actually mean?

On one side, it’s about the right team: a mix of long-run software developers, their feet firmly on the ground, always looking for the best solutions to clients’ projects; and high-energy, star-eyes devs who feel like changing the world.

On the other hand, it’s in the way we work: updating our mindset, processes and methodologies is an important part of the game.

To put things into perspective, let’s have a look at the (non-exhaustive) list of software technologies we deployed for the last 30 years, then discuss how our work changed during the years.

30 years of software technology

First, let’s take this out of the way: during the last 30 years, we took on a lot of software technologies and outgrew all but the recent ones. Yes, 30 years ago in software development is ancient history, but (more important) Berg Software keeps evolving, whatever challenges come our way:

• Back in 1994-1995: we were building with FoxPro, DOS, Windows
• 1996-1997(-ish): Unix, C, VisualC++, ObjectPascal si Delphi, Lotus Notes, Domino Server, Catia
• 1998: Visual Basic
• Around 2000: HTML, Java and ASP for web applications
• 2000-2012: a boom of frameworks, which we used as they came, for example:
  • new Java frameworks (e.g. from Servlets, Swing, JSP, JSF, RCP, up to Struts, Hibernate, Spring)
  • new .NET frameworks (e.g. C#, VB, ASP, Windows forms, ASP.NET, MVC, WCF, Entity Framework, WPF, etc.)
• By 2007: first BI work
  • SQL Server+
  • ETL (DTS morphed into MSIS/Multi-source Service Integration, now SSIS/SQL Server Integration Services)
  • custom-developed data integration engine,
  • multidimensional databases (at first Analysis Services, then custom engine developed by Berg Software)
  • custom development of data visualization and analysis tools
• 2007-2008: JQuery
• Starting 2012: J2EE, Spring, SAP technologies (SAP Fiori, SAP UI5, OData, ABAP, NetWeaver, HANA)
• As of 2012: virtualization (cloud solutions via AWS, Microsoft Azure, OTC/Open Telekom Cloud)
• Beginning 2012-2013: Bootstrap, GWT
• Between 2015-2020: various JavaScript/TypeScript frameworks for modern Web applications: from AngularJS to Angular 12 and React
• 2018: DevOps tools (Docker, CI/CD, Kubernetes, Terraform, Ansible, Istio, Jenkins, GitLab, etc.)
• Also 2018: BigData (Elastic Search, ClickHouse, Kafka, Spark, MongoDB)
• Currently: we’re looking into the ongoing trend of frameworks that solve specific needs (e.g., multiple UI frameworks)

Got your head spinning? Let’s clear it up a bit by looking into how these technologies changed the way we do software development.

30 years of business (of software development)

When asking our older more experienced colleagues “How did the business of software development change during the last 30 years?”, they got “Nothing! It’s still software development.” But then, they started firing up: oh! things are waaay different post-internet boom from what we did in the 1990s.

Working with clients: in-person vs. remote

A project is still a project. Understanding clients’ needs is still the starting point. Doing high-quality work on exciting projects, and standing proud of the outcome, are still the main drivers of any software developer.

But then, web-based communications make everyone’s lives much easier. At the very least, help reducing business trips between the client and the software development company. For Berg Software, the changes have been dramatic. Just consider that pre-2000 (prior to Romania’s joining the EU), each trip to a client’s HQ would take 16-20(-28!) hours of travel, for two/three days of meetings.

So nowadays, we probably have the precisely right mix: in-person for the infrequent high-touch situations; remote for the regular, day-to-day work.

Methodologies: waterfall vs. agile

The other big change is the move from classic/waterfall to agile methodologies, due to mindset (rather than technological) evolution.

With waterfall, projects would (almost always) be over-specified. Detailing every single window and button of a software product can result in months of delays, 500-page annexes, and artificially increased prices. Of course, in the end, there’s no such thing as “perfectly specified”, so one could expect further development / corrections / delays / costs.

Enter agile, where software has to solve client’s needs within a fixed budget. Software development goes through shorter iterations (e.g., 2-3 weeks each) that solve specific topics. At the end of each iteration, everything needs to be perfectly functional. Then, based on established priorities, move to the next one. This way, the project advances in the right direction, so in the end, the client *does* get what they need. If anything ever changes, it’s the small stuff. Some 90% of needs will be implemented within the assigned budget (100% of the must-haves), and the software product will function as intended.

(Yes, we are aware that agile can also get to cost a lot – but that’s with projects where things change *a lot*).

＿

If we were to summarize 30 years of software development, it would be: “You name it, there’s a high chance we excel at it.” The good part? We have the skills (and the processes) to take on whatever comes next.