Enterprise development is changing, and we need to change too
In this post, I'd like to address some changes I've been seeing in the way enterprise applications are developed, and how this affects how we, as enterprise developers, need to change along with that trend. We need to learn new skills, change the way we look at our every day job and the requirements it has. We're accustomed to working in an Agile way in our day to day lives, so look at this post as a retrospective of our own work, and the implications it has.
Observing the history of the enterprise development world
But let's start out with why I'm interested in these changes in the first place. My job at GROUP9, the company I work for, is twofold. Partly I'm a consultant working for our various clients, often in the role of architect, helping our clients in creating software solutions and in general becoming better at delivering these solutions. However, my other, internal, responsibility is that of competence manager. Basically that means ensuring our consultants stay the smart people they are, and that means reflecting on what skills are needed in our profession every now and then.
When I started out as a developer, I was taught the basics of Java development: Java SE, Java EE (or J2EE as it was called back then), Spring, Hibernate, log4j, etc. Those were the basic building blocks which we teach our developers to create applications. Of course, that's not enough to build mature applications, so we also educate them process methodologies like RUP, Agile,. We teach them how to design applications, design patterns, architecture etc.
Most importantly though, we taught them a "common sense" on how to build enterprise software. This means we taught them topics like databases, transactions, remote method invocation, distributed systems, security. The enterprise world was quite easy to understand and divided into the big chunks of people doing Java EE, or people doing Spring. However, knowing these underlying principles of software engineering allowed you to easily move from one platform to the other. You could effectively and efficiently create software on these platforms, even if you didn't have the full knowledge on how to use them.
In practice, given the general understanding and a sound knowledge of how enterprise systems work, adapting to each of these different environments was "easy". It's just a matter of learning how to work with the specific tool, and "Bob's your uncle". More importantly, we often saw that people who knew the underlying principles were often way more effective than people who just knew the trick of applying a specific tool. Think of this as being a carpenter: if you know how to handle wood, it doesn't matter which brand of hammer you use. Or like being a car mechanic: if you know how cars work, it doesn't matter whether you're repairing a Honda or a Mercedes.
The ideal case is of course to have someone who knows both the principles and all of the tools by heart, but in a highly contested job market, that's often a luxury we don't have.
In that world, there were a lot of certifications, like the Sun Certified Java Programmer (and later on of course the Oracle variants). These certifications required you to be a human "compiler". Just know the tool by heart, and even if you didn't have any clue on how to use the tool effectively, you could still easily pass the certification. This lead to a world where a lot of the more proficient developers frowned upon certification. Having certain certifications didn't in any way imply that you knew what you were doing or applying it in the right way.
Fast forward to the modern world
- In modern, often micro-service based, architectures, there is a highly increased usage of tools to solve the various business challenges were are facing. We are building software at increasingly higher levels of abstraction using more pre-made components and tools.
- The complexity and impact these tools have on our ability to deliver our solutions is constantly increasing. Components are often highly complex, require us to think cross-domain or into domains which were previously shielded from enterprise developers, and when used wrong have a profound (negative) effect on the workings of our solutions.