Skip to main content

Back to Basics: Why the principles that built our industry still matter today


Looking ahead to next year, I want to talk about Abstraction, Encapsulation, Cohesion and Loose Coupling as it seems they are missing from a lot of modern software design.

Back to Basics: Why the principles that built our industry still matter today

There are only three things certain in life: death, taxes, and constant change in software.

For decades, we’ve tried to limit that change. Up‑front design and predictive methodologies promised control, but too often delivered the wrong software for the user.

In the late 90s, Kent Beck urged us to embrace change through methodologies like Extreme Programming and concrete practices such as Test‑Driven Development. These weren’t trends, they were reminders of fundamentals we already knew.

Design behind interfaces. Keep responsibilities narrow. Make dependencies replaceable.

These boundaries matter, from functions and classes to services, systems, and infrastructure. These ideas have been with us since the 60s and 70s. The challenge isn’t invention, it’s remembering to apply them all the time and everywhere.

We can’t do much about death or taxes, but we can remember how to make software easier to change.

Attend this session to rediscover the timeless principles that make software resilient. You’ll leave with practical reminders you can apply immediately, so your systems evolve gracefully, no matter what the future throws at them.

Motivation

Modern software teams often talk fluently about delivery, scale, and velocity, yet struggle to consistently apply basic design concepts that manage change. 

The result is not a lack of progress, but a quiet erosion of engineering fundamentals. This talk aims to make those principles explicit again, relevant again, and usable at every level of a system, from top to bottom.

Comments

Popular posts from this blog

Catalina-Ant for Tomcat 7

I recently upgraded from Tomcat 6 to Tomcat 7 and all of my Ant deployment scripts stopped working. I eventually worked out why and made the necessary changes, but there doesn’t seem to be a complete description of how to use Catalina-Ant for Tomcat 7 on the web so I thought I'd write one. To start with, make sure Tomcat manager is configured for use by Catalina-Ant. Make sure that manager-script is included in the roles for one of the users in TOMCAT_HOME/conf/tomcat-users.xml . For example: <tomcat-users> <user name="admin" password="s3cr£t" roles="manager-gui, manager-script "/> </tomcat-users> Catalina-Ant for Tomcat 6 was encapsulated within a single JAR file. Catalina-Ant for Tomcat 7 requires four JAR files. One from TOMCAT_HOME/bin : tomcat-juli.jar and three from TOMCAT_HOME/lib: catalina-ant.jar tomcat-coyote.jar tomcat-util.jar There are at least three ways of making the JARs available to Ant: Copy the JARs into th...

Write Your Own Load Balancer: A worked Example

I was out walking with a techie friend of mine I’d not seen for a while and he asked me if I’d written anything recently. I hadn’t, other than an article on data sharing a few months before and I realised I was missing it. Well, not the writing itself, but the end result. In the last few weeks, another friend of mine, John Cricket , has been setting weekly code challenges via linkedin and his new website, https://codingchallenges.fyi/ . They were all quite interesting, but one in particular on writing load balancers appealed, so I thought I’d kill two birds with one stone and write up a worked example. You’ll find my worked example below. The challenge itself is italics and voice is that of John Crickets. The Coding Challenge https://codingchallenges.fyi/challenges/challenge-load-balancer/ Write Your Own Load Balancer This challenge is to build your own application layer load balancer. A load balancer sits in front of a group of servers and routes client requests across all of the serv...

Do software engineering professionals still read? - survey results

  In order to gauge the potential audience for my book, So you think you can lead a team? , I conducted a small survey of my colleagues, co-workers and anyone from Linked. I read regularly, for work and pleasure, and assumed everyone else did too but did the responses I received confirm this? I polled 173 people, all within the software engineering field (including Product, etc), with a range of ages and years of experience in their role. What surprised me the most was that the majority of people, young or old, just starting or seasoned, still prefer reading physical books to blogs or e-readers. It also seemed that the older and more experienced were the most keen in learning more, and reading to expand or update their knowledge.  When it comes to reading habits between different roles the survey showed that software engineers and team leads read more regularly for their career than other roles, with 55 years old and over and 16+ years experience being the biggest readers over...