Should Devs use cool Tech?
If your experience is anything like mine, you know that software developers can no longer pursue technologies and techniques just because they sound cool or intriguing. We must justify everything that we do. I think that has not always been true, but it is a good thing it is true now. I think the best justification for using any technology or technique is to provide value to the business. Vaughn Vernon “Implementing Domain-Driven Design”
This is why we can’t have nice things
In a recent project, a developer on the team wanted to use a certain NoSQL database for persistence. He had good technical reasons to do so. But the client’s Enterprise Architecture opposed the decision as they had approved a different database as part of their strategy. In the end, it resolved well to the joy of our developer. But it easily could have gone differently.
Indeed, in my five years of experience in Canadian Enterprise IT, I find that some clients I work with have very rigid standards when it comes to using cloud services, databases, and programming frameworks. Even though they are all starting or on the path of a cloud-native journey, they still don’t fully appreciate the value of the provision-as-you-go nature of the cloud and use-the-right-tool-for-the-job.
An adage that has come into being over the past 20 or so years is: “Don’t allow your developers to use whatever they think is cool, follow the standards and approved technology stack and guidelines”. One possible reason raised for this is that when it comes to “cool tools” and letting developers choose what they want, it ends up in a fragmented landscape. The churn in IT also means that there will be issues in finding developers to maintain the software built so far. At the two extremes, think of how easy it is to find a Java developer and how hard it is to find a Go developer (at least in a Canadian context).
Another issue has to do with where does power and decision-making lie. If you let the developers make all the decisions, what is left for Enterprise Architecture to steer the ship. EA is accountable to the business and ultimately to shareholders and is relied upon to minimize costs and increase efficiency. Those rigid standards have a financial, business, and technical reasons. Reasons that a developer might not see. In the example given above, the developer’s initial choice involved licensing issues, thus costs.
Finally, the question is raised about how much a developer does their own trade-off analysis and considers all the angles when it comes to their decisions. The whole Architecture role has been flourishing specifically because of the idea that developers can’t be put in charge of software projects. You need someone or multiple people to guide the software development enterprise.
Ruby off the rails?
Some of the above concerns are valid. Indeed, even today, it is a lot easier to find developers who know Java vs Go. I remember one client I was consulting for in the past who got into an argument over the use of Go in the project precisely because they didn’t find a large enough talent pool in Montreal.
However, good developers keep their skills sharp and keep learning new tools, languages, frameworks, and clouds. This is the hallmark of a good developer and what distinguished her from a code monkey. And such developers are not usually attracted to legacy shops that mainly operate on old technologies.
Furthermore, one might argue that when it comes to technology choices it’s a toss-up. The same client who argued against Go also argued with us over a NoSQL technology and forced our hand to use something more traditional (sic SQL). Years later the NoSQL database is one of the hottest technologies on the market.
Today’s bleeding-edge technology if adopted could become tomorrow’s legacy technical debt that no one wants to touch. A big issue with Shopify today for example is what seemed in their early days a good choice: the adoption of Ruby on Rails as their core framework. While Java has withstood the test of time, Ruby has not. Try to find a good developer today who wants to touch Ruby. Indeed, many legacy systems in the past that power the current enterprise were wildly vetted from an EA perspective. Which bank today doesn’t have a mainframe somewhere? Which bank today can easily find a COBOL developer to hire?
Puzzled landscapes
The concern about fragmented landscape, however, seems a bit shaky. The most legacy of enterprises have software written in a variety of languages (COBOL and Java for example), and frameworks (.NET and J2EE as another). Add to this COTS (Commercial of the shelf) software that the enterprise ends up modifying and extending, and most enterprises have a fragmented technology landscape.
The microservices advice to have polyglot persistence and use the best language for the job looks like a new way to produce technology proliferation, but it just isn’t.
At least with adopting modern cloud-native design the impact could be mitigated to pizza-team-sized services. And should their technology become deprecated, the modernization through rewrite challenge would be small.
Architectural humility theory
A little humility from Enterprise Architecture is warranted. It doesn’t hold God’s all-seeing eye’s foresight. While experience speaks, and Enterprise Architects boast a lot of it, the developer who is close to the action knows a thing or two and should be listened to.
Some standards are required (e.g., PCI for Banking), but most of the time they result from misguided legacy thinking and decisions. For instance, the good old Uncle Bob’s solid principle of Don’t Repeat Yourself is challenged by Microservices design, which eschews the use of common libraries lest to avoid coupling.
At the same time, by trying to restrict fragmentation of the technology landscape the enterprise will miss its chance to modernize. It will get stuck with applications that are hard to maintain, prone to security vulnerabilities, and for which they can’t find developers.
Great man theory of software development
The 19th century’s Great Man Theory states that history can be explained by the impact of great individuals. This has its counterpart in the software world with the Super-Developer effect. Projects are made by one or more Super-Developers: the lone contributor who moves the needle farther than anyone else on the project. The developer at the start of the article is such a Super-Developer. He was able to see farther and produce more than anyone on the project. Bill Gates has been widely quoted to say, “a great writer of software code is worth 10,000 times the price of an average software writer”.
领英推荐
The Great Man’s theory has multiple refutations one of them comes from William James as to the effect that history is determined by the various actors in society, molded through the generations. This can be seen in the enterprise software world with the view that it’s not a single individual that makes the project work but a whole team
We are in the process of the industrialization of IT with the average grunt flavor of developers at the lowest ranks. Enterprise IT wants to create software factories that they control through standards and take away any decision-making and creativity in the software craft, or at least displace it higher up the chain where architecture resides.
In the modern software factory, a team of story writers is employed and controlled by the functional architect who makes sure every aspect of the software is well described. The software grunt will take the procedural recipes written in a behavioral descriptive language and transform them into a computer-readable language. All aspects of creativity are gone in favor of tough standards.
This might be called for in the Modern Enterprise. Sweat usually makes software projects succeed. Debugging is known to be 90% of what a software developer does. And fixing bugs in software takes up most of the development cycles. The approach to use test-driven development is used to prevent bugs from the get-go (as much as possible). But that too results in the industrialization of software development. TDD takes away some aspects of creativity from the developer.
Think of the developers
Yet when we get down to it, it’s ultimately your software developer that makes your code work:
Today it is still possible to create an entire software product with just one developer. This is how start-ups are born. One developer with a dream! In the enterprise, all the other members of the software development team should realize that they stand on the shoulders of the developers.
A new partnership
With that in mind, making the life of the developer easier can go a long way. What is called for is a new partnership between Enterprise Architecture and developers. What EA should realize is that developers are not chasing cool tech for the fun of it. Most of it makes their lives easier and the software better. So, removing red tape and fostering a culture of experimentation is key.
Rigidity slows down delivery and stifles innovation. In the Cloud Native world of provision-as-you-go and build your Microservice in your framework of choice, it’s exactly that. You have more choices in the cloud, and you can leverage them to achieve an architecture that is always up to date with the latest technologies and standards. This state is desired not because it is cool, but because problems of the past have been easily resolved using present-day tech (Think page long SQL queries versus API first development approached backed by functions using NoSQL).
Enterprise Architecture can still have some guardrails to steer decisions. A good approach would be for EA to determine the process to select the technology. Maybe even limit the number of technologies to use. Then request from developers to write concise reports detailing the specific functional and non-functional requirements that are addressed by the new technology. Such reports should be validated in less than 2 hours and if the cool technology makes good sense, then so be it.
To borrow a reactive Microservices analogy, what is needed is Enterprise architecture as a Choreographer of the IT department’s technologies and not a Conductor with strict rules to follow.
A little magic in the factory
Information Technology’s push to industrialization might have a place under the sun or might become a new standard. But developer creativity should not be thrown to the wayside. Maybe for those legacy enterprises, a compromise could be found where an R&D center can be put in place to try new technologies and infuse young blood in the corporation.
Or in the factory, every few cycles of development the old rules get revisited in an app to make sure they are still valid. What if you were to re-examine a medium-priority application that was written a few years ago and see whether the standards still apply? You might do so in the context of rewriting it. The impetus could be the Digital Transformation most CIOs are pushing for today. They as well as possibly the bean counters could be convinced to go this way in the context of legacy modernization and moving to the cloud.
Epilogue
As an architect moving up the ladder I am constantly in awe of the new talent and how they can move the needle and shape software. I understand the drive of Enterprise Architecture for standardization, yet don’t want my superstars to get discouraged and move away from my projects because of some antiquated standards. I believe that the best thing an architect can do is be the advocate of the developer to the higher-ups and help them realize that until the problem of Artificial Intelligence is solved, it’s developers that will make the computer do what the business needs.
Sometimes I must steer the ship myself. I keep myself fresh by going in, digging into the code, and writing some parts of it or proofs of concepts. But at the same time, I realize that the more meetings I attend with architecture, the business, and the users the less time I will have to code and be in the weeds. Therefore, I rely on my developers to tell me what is best from a technical perspective.
So yes, developers should get cool tech, but with some guidance and for a purpose. Eat your vegetables and you get dessert.
I would like to thank Martin Brassard from IBM for a chat I had with him about the topic of this article and for some of his comments that I used
I would like to thank Max Baburin for reviewing this article and for some of his comments that I used