Internal Facing Projects

I want to share a few experiences I’ve had in recent years involving projects that were for internal use and the differing attitudes I’ve seen expressed towards their development.

At a previous company, I was asked to step in and manage a project that was built by a number of engineers that had left the company. There was no more institutional knowledge. That happens, not the end of the world. When you are first starting on a project, you always have to get your feet wet. Ideally, there would be team members to help onboard you, but this wasn’t the case.

So naturally, myself and the other engineers on my team started out like anyone else would. We looked for documentation. Nada. I could hear the ghosts starting to whisper: “It’s internally facing, why would we write documentation?” We started reading the tests like they were documentation. Not a lot of coverage to speak of. Again, more ghost whispering: “Why would we waste time writing extensive tests, this is just internal facing.” So, we dove into the code. It was no longer just about hearing ghosts. We found dragons as they say. Don’t peak around that corner of the code. Dragons. Don’t assume patterns were followed. Dragons. Continuous delivery and deployment foundation? Nope. Needless to say, we had our work cut out for us if we were going to successfully own and operate that software regardless of who was going to be using it and relying on it. One thing was clear, the previous engineers treated the development of the service differently because it was internal facing. We knew these engineers and knew they were good at what they did, but clearly their attitude was different towards this particular project.

And this is not the only time this has happened. I’ve “inherited” or have been asked to take over and operate a number of projects in the last five years that have been internal facing, meaning only other company employees will interact with the service. All seemed to share a trait, the work was subpar. Maybe these were side projects. Maybe they didn’t receive appropriate funding and weren’t staffed right. Maybe the order was to get something out there quickly. But I still can’t help but feel like something else was afoot with all of these projects and I have a hard time wrapping my head around it. I can’t wrap my head around the attitude I’ve seen expressed towards internal facing projects.

A user is a user, whether the app you are building is internal facing or external facing. As engineers, we take pride in the craft and treat our users with respect. Treat the other engineers that are going to help maintain and operate the project with respect. There is no reason to build lesser quality products just because it is internal facing. If it is not a prototype, build it to be production ready. Even if you don’t have the appropriate number of engineers allocated, write tests. Even if the user is just the person in accounting down the hall, write documentation. You may ship less, but at least what you ship can be supported, understood and used. You’re building it to be used, right?

I don’t believe the fallacy that writing tests take longer. That simply hasn’t been my experience. In fact, I think writing tests makes everything more straight forward, especially if the tests are written first. Ultimately, that means less spinning and more delivering.

And basic documentation can be accomplished. Time box the effort or something. But users need documentation, even if it is just a few “getting started” instructions in the README.

After years in the industry, we develop a workflow and any experienced engineer I know is not going to alter their workflow if the project they are working on is internal or external facing. If you always practice TDD, I don’t see why you would stop just because the project is internal facing only. Experienced engineers take pride in their craft. They strive for quality software, which include tests and documentation.

There are a lot of companies growing and transforming and relying more and more on software. A lot of the projects will simply be internal facing. The main project I am working on right now at Nike is an internal platform. In order to get adoption, we just introduced documentation. Right at the top of our UI, can’t miss it! We’ve pointed people to it and they’ve thanked us, like it was some special above and beyond effort. We thought it was just a given. Our internal facing project has hundreds, if not thousands, of users. Many of whom, we may never meet. Just like a SaaS made publicly available, we won’t know all of our users on a first name basis, but we are going to treat them like they are external paying customers with demands for the basics like documentation. Maybe we’ll end up influencers for the other internal facing projects, I don’t know.

My experience has taught me that some environments contribute to the attitude towards internal facing projects. That’s a shame. However, I see engineers taking pride in their craft every day. I see the industry promoting talks about our journeys and how we’re evolving. Personally, I’m hopeful that the attitudes towards internal facing projects will change for the better. I’m around more and more engineers every day that I see not accepting the subpar attitude and challenging it. We’ll get better as an industry I’m sure, otherwise we’ll all be stuck operating and maintaining projects that we find painful and frustrating.

If you are an engineer being asked to work on an internal facing project and being asked to cut corners simply because it is internal facing, ask why? Bring it up to your manager and ask for clarification. Maybe the planning and scope just need better definition. Maybe the feature requirements need to be gathered more. But cutting corners just because it is internal facing is short sighted and not doing anyone any favors. Managers have a responsibility to defend doing quality work and explaining iterative processes to the business. That doesn’t change if it is an internal or external facing project, in my opinion.