Developing for the Enterprise: How My Software Development Changed Working for IBM

I've been working inside of IBM for about 18 months as a Python developer and DevOps engineer. Before that, I spent most of my career in 'small businesses', where the biggest organization I joined was 200 individuals large. When talking with developers looking to work for IBM, I often get asked about what tools I use, with people often expecting me to be coding in Fortran on a 30-year-old system.

The truth is that I haven't noticed a great deal of difference in the tools that I used compared to my previous roles. Our team uses modern software tools like OpenShift, NodeJs, and Cloudant (a cloud-hosted flavor of CouchDB) to deploy our software solutions, which isn't too horribly different from what I did in past roles. What I have noticed is that enterprise development has altered how I approach software problems, enough that I can now point to certain elements of my work as an 'enterprise-feature'.

Here are three of the biggest changes I've made to my technical development when working in an enterprise environment.

Increased Focus on Readability and Usability for Software Features

Modern software development is often open and collaborative, but the truth is that in small organizations, your software is very likely only going to be viewed by a small number of people you know well. When I used to create automation scripts for BI projects in previous roles, I knew the five people on Earth who would view it, and they were all within Nerf gunning distance from me. Just having the foresight to put down a README in case someone had to read it in the future was considered a 'pretty good' move. In all likelihood, the person who would be running my automation scripts in the future would be me, and if I left, I might be asked to send over to one of my peers to figure out in the future.

But during my time in enterprise development, it's a safe assumption that a script I write today will be actively used by my team within a reasonable time, maybe even someone who I don't know incredibly well. For them, the only entry point they have to my script will be what I write down in my documentation and the actual code itself. So, if they attempt to use it and there's some problem with it, the first thing that's going to happen is that they're going to come to me to ask me questions. If I didn't put in the time and effort to add code comments, a fleshed-out README and sufficient logging and testing, I'm going to get a LOT of questions, and maybe even a meeting.

It's not that I couldn't produce a piece of software without these things, especially during emergencies where working fast is paramount. But if I do produce something without the right amount of documentation, without being readable, without having the proper testing, I WILL 100% certain get a message from a (rightly) confused peer and will likely have to use my time to help resolve it. Sometimes this is inevitable, but I significantly reduce the chances of having these encounters by putting in the time to document my software, add proper testing frameworks, and writing readable code. This does not have to be super extensive (and honestly your organization should have standardized ways to handle all of these when working at an enterprise scale), but it does need to be sufficient enough that you can walk away and a relatively capable peer can use it.

I found success in this while building an automation tool for rolling out configuration changes to a large number of our software components it Github. The software I was using had a number of complex components, and so I started my development by writing my Readme, with the exact steps I needed to follow, variables that needed to be accounted for, and how to run this script in different circumstances. Then I built my tests and worked my way towards my solution. A few weeks after this was completed, two of my peers took the script and rolled out their own configuration changes without consulting me (I only found out after I was asked to review a PR in Github). This saved them time by not having to develop a solution and saved me time by not having to be involved with their solution, a great example of a WIN/WIN.

Utilizing Simple, Repeatable Frameworks for (Almost) Every Software Solution

While I can't say this is something that is strictly true for enterprise organizations, I do notice that my enterprise experience has pushed me more toward repeatable, easy to follow software patterns for handling my problems over the most 'ideal' software framework for the problem.

When working with small organizations, I was finding that a lot of my software creations were often one-off solutions that were used just to get a job done. I would start off with a blank GitHub repository, think of whatever solution I wanted to build, and then build from there. I didn't think about software frameworks because I preferred to let the problem dictate the framework. This was equally true for the libraries I used… I wasn't incredibly consistent from project to project on which libraries I connected to, often favoring whatever made the job the easiest for that given project.

But during my enterprise work, I rarely start with a totally blank template for my work. In the last three feature requests I pulled from the backlog, even features that were quite novel, I always started with my library of patterns that I used (CLI tool, one time data pull from CouchDB, automated email, etc) and then built from one of those templates. While I won't necessarily copy the original script entirely, I will rely on that pattern to create the 'framework' for building my script, even if there are some drawbacks. One common drawback is that some problems are quite simple to solve and don't require a lot of overhead, but I might use a bulky framework anyway.

Why do this? Because it significantly reduces the speed to getting the feature into production. If I didn't use a framework and, instead, tried to build something novel each time, I'd run into major brain drain solving 90% of the same problems:

• How do I want to handle my project structure?
• How do I want to structure my classes and functions?
• How do I want to handle my testing?
• Which library do I want to use to handle my CLI?
• What do I need to do to get this solution automated to deploy to our cluster?

These are all important problems, and something you should put serious effort to solve when you're working on a new software paradigm or need to design a paradigm for your organization. But once these base solutions are understood, it's just a matter of finding what's new and then solving just for that problem. This allows me to not have to think about my solutions and, instead, just focus on solving the problem as fast as reasonable while still following our internal coding standards and expectations. Now I'm able to produce solutions with a predictable cadence because my framework is well defined.

Using Simple, Flexible Software Patterns (When Not Forced Into Complexity)

When I used to work on smaller software projects, life was actually quite simple. I didn't know it at the time, but my requirements were really just those that were needed by either my customers, my peers, or the organization I was consulting for. Outside of those requirements, I didn't REALLY have to worry about other problems. I had some of my own standards I wanted to use, but the relative simplicity of my requirements allowed me to very flexible with how I built my software.

What did this mean? It meant that within my software, I could get quite complex with how I wanted to solve my solutions. I could have large classes, nested function statements, external libraries with very specific and niche use cases, without much worry that it was going to cause an issue. When the requirements of your projects are relatively simple, your code can afford to have 'unnecessary' complexity and can even be a bit obtuse. So long as it solves that direct problem, it's not an issue.

While working within an enterprise organization, the requirements are AT LEAST an order of magnitude more complex than they are within a smaller organization. This is because there are, roughly, an order of magnitude more people who are interacting with your code, whether that's directly or indirectly. This might come from the following places:

• Product Owners
• Compliance Organization
• Management Team Requests
• Operations Team
• User Community Committee
• Open Source Contributors

And within each of these, there might be multiple levels of 'requirements' that may filter down to your backlog.

When you have this many features you have to manage, it's inevitable that there will be large pieces of your software tool or features that you don't have many options with. When enough of these requirements collide, they can make the software difficult to develop while still hitting your design standards. What ends up happening when you live in this environment long enough is that when you DO get a choice, your inclination is to build software that is simple and flexible enough to meet these demands.

For me, this meant that I started favoring built-in python packages over external libraries because build-in packages are more predictable and easier to integrate than even very popular external libraries. I started to use very verbose variables for all of my scripts because it made it easier to know where everything was going. I started spitting out some of my functions into classes into different files because it meant that the truly 'new' logic could sit in my main script. This doesn't mean that I can avoid all issues with feature creep in my software, but it does mean that I'm injecting as little complexity as possible with my own development to make room for outside requirements.

Conclusion

While there are many things I learned during my time as a developer at IBM, many of the lessons I would just consider "good software" practices. But these are some of the lessons I learned that I can attribute specifically to working within an enterprise development, enough so that if I joined a smaller organization I'd have to 'unlearn' these lessons to become better equipped to handle their challenges. But some I'll be very reluctant to give up.

If you're interested in software development and want to learn more, feel free to connect with me on LinkedIn.