In the past I’ve talked about emergent requirements. You know those…those are the ones where you’re chugging along, building your system, you’re pretty far along, and then you have a meeting with the customer or product owner and they say something and you realize, “Wait a moment, they think the system should do X!” And now you’ve got a scope creep problem.

Yeah, I’m not talking about that.

I’m talking about, in the enterprise world when you’re building a software application, there’s a whole bunch of requirements that it’s usually just assumed that you already know. I’m not talking features, I’m talking support, maintenance, integration, things like that.

What operating system will your app install on? Windows? Linux? Something esoteric like IBM AS/400? Or maybe this is running on a K8 cluster and actually they are expecting you to deliver a container image.

How do you log in? Are they expecting you to use their local Active Directory? Or integrate with their SAML provider? Or use Google or Facebook identities?

Oh, and are all your log files going to their centralized log server?

And what happens if you need to upgrade the software in place, either for a bugfix or a new feature? Can you system be upgraded via automation or is it a complex process where someone is manually replacing a bunch of DLLs?

I’ve been on many projects where I’ve joined partway through, realized no one on the development team had thought about the items above, and then when I ask the product owner or customer there’s confusion because they just expected that we knew already. This is ESPECIALLY true for internal projects, because it’s assumed “everyone just knows how our organization’s environment works”.

The challenge with all of these is, none of this is stuff you are really taught. If you take a class on Python or Java development for example, they might mention some of these things in the requirements gathering phase. But generally speaking many of these types of requirements are things that you’ve only learned via experience, because one time you went to deploy your .NET app and realized that the standard Windows IT image is Windows Server 2008 running .NET 3.5. Oops.

This is why you should always be learning, not necessarily just new technologies, but learning how to lead projects to success. Because it’s not just about writing code, its about all the things you need to do to get that code into a place where it actually brings value to your customer.