Information: The hidden key to software engineering success

Why supporting your team’s information systems should be one of the primary considerations for software projects.

Good developers become great when they have great information.
Great teams become excellent when they share information with each other.

The stakeholders’ linchpin

When developing software there are several primary stakeholders that project teams must take into account to be successful.

The exact priorities vary, but generally managers balance their focus between stakeholders like Users, Customers and the Business etc.

Over the course of my career, however, I have noticed one vital stakeholder consistently and inappropriately pushed down the list. This occurs even when that stakeholder directly affects outcomes for every one of the project’s other stakeholders. Yep I am talking about the Project Team! I would go so far to say they are actually the “linchpin” of your software project. The reason I like to call software teams a “linchpin stakeholder” is for the simple reason that, if you fail to support them, the project will fail to deliver value to it’s wider stakeholders. The Project Team is simply crucial.

There are various aspects of team support we can consider here, however, the biggest problem I see in this area is when a business ignores the way each team member gets and uses information in their daily practice.

Team support is all about managing information

I want to be clear about what I don’t mean by supporting a team. I don’t mean giving everyone a pay rise, getting fancy office fixtures, installing a ball pit, pool table, a pinball machine and offering shoulder massages twice a week.

What I am talking about is refining your team’s information environment and systems. In software engineering all the tools, processes, environment, infrastructure and cultural factors we are presented with are all information vectors.

These vectors might include things such as:

• Knowledge sharing
• Collaboration tools (Source control, Project Management Tools)
• Ritual and processes
• Source control
• Infrastructure
• Application architecture
• Code culture (eg. Clean code, Git hygiene)
• On-boarding and hiring of new team members.
• Conferences
• Supported study
• Mentoring
• Pair programming
• Social culture

Ensuring each team member has the ability to get access to, and share the information they need to work and collaborate as effectively as possible is why those tools exist.

These things are often neglected, especially in a start up environment, yet they all contribute greatly to the effectiveness of a project and the longevity of the startup.

Why are information systems so important?

It can be argued that Software Engineering as a discipline, is effectively doing nothing but rearranging information to achieve certain outcomes. Therefore it stands to reason, developers having access to great information will deliver great outcomes for stakeholders.

This is especially true for junior developers on your team who desperately need the support of great information in order to succeed. Good information systems will be the difference between them making poor decisions and good ones.

That being said, there are several benefits for encouraging a team’s access to and ability to share information. The correct environment for your team will enable greater productivity and better performance through effective collaboration and joint learning. That great productivity actually all funnels value directly to your key stakeholders.

So how can you look after your team’s information environment?

Great processes create great organisations. Here are some of the things project teams should be thinking about.

Hiring great people

Great engineers are simply people that have a huge amount of information at their disposal. The more information they accumulate with experience the better decisions they will likely make and the more information they can share with the rest of the team. So you get ahead by hiring great people and you stay ahead when they share that information with the rest of the team.

Code review like crazy

Code reviewing is probably the second best way to share information in your team after pair programming. If you have more than one developer, encourage a code review culture. In fact, there are so many advantages to code reviews, that it could be argued that for an organisation not doing so is a questionable practice.

Code reviews ensure your application actually fulfils requirements, increases consistency, lowers cognitive code overhead, increases knowledge transfer drastically, can be used as accountability, allows for the creation of better estimates, removes a single point of failure within a team, makes your application easier to reason about & maintain, mitigating the cost of defects and mentoring junior developers …all at the same time!

Communicating well to avoid technical debt

Accidental technical debt is a huge problem that slows your company’s effectiveness over time and in some instances can destroy your company completely.

Proper information processes prevent accidental technical debt by ensuring every team member understands, communicates and discusses why debt has been leveraged and delivers them the power to pay it off as appropriate. It also allows for strategic accrual of technical debt deliberately for specific business reasons via wider consultation.

This is not limited just to the technical team either. If business strategies and requirements have not been properly communicated to the development team one of the main resultant artefacts is extra accidental technical debt. An information problem often results in a technical debt problem.

Constraining via tooling to foster better communication

Increase information flow by enforcing your processes with tooling. There are a huge number of benefits that quality tooling can bring to a teams workflow. These constraints encourage information flow.

Common checks, send signals to team members about the values of the team. Eg. enforcing passing tests or code reviews, using linters to disallow poor practice, using pull request templates to enforce documentation. These all act as queues to make a developer understand what is expected of them. Standard tools like custom bootstrappers or centralised config, communicates that your team values consistency. Developers should question standards consistently and weight up decisions as to refine processes as teams navigate and contribute to the changing culture of the team.

By using tooling to enforce workflow, engineers don’t need to waste time thinking about the ramifications of small poor decisions that add up to larger issues. This means they can think about building the business functionality wider stakeholders expect them to build.

Architecting as if your engineers are visually impaired.

Great system design means engineers are able to think myopically. The less information a developer needs to work on the code the better. In fact within Domain Driven Design bounded context means a model’s applicability is limited to specific areas of the system. CQRS takes this further and suggests that the model a read process needs to do it’s job can be different to that which a write process requires.

When an engineer is working on a bug or feature, they should not need to care about other parts of the stack or even know how the rest of the application works. Armed with the basic patterns, they can hack away, in a neatly boxed off area, blissfuly unaware of the overall system complexity and still remain productive.

Each feature or request chain should be arranged in such a way as it can work or at least can be tested as a separate application. Isolate your dependencies wherever you can. This is a sure way to increase velocity and efficiency.

Here you also constrain poor design to a single feature which can be flagged and refactored as part of code review. Ideally as a side effect you will have setup functionality that can be run in different environments and scaled independently. By limiting an engineering task to an isolated feature at a time you will increase their velocity as they need not cross coordinate with other team members.

Keeping your organisation’s knowledge close to your code.

The knowledge of why approaches have been taken as well as knowledge of the way to work with the patterns setup should ideally be held as close to the code as possible.

Create Issues and PRs in meetings to provide documentation. Avoid using separate knowledge systems that engineers rarely use. Make sure the information that engineers need to be effective is at their finger tips.

This ensures new and remote team members will be able to easily understand rationales for code patterns and make effective decisions about how to conduct their own work.

Remote first is a useful abstraction that promotes sharing and documentation

Great organisations are great information systems. Automate your documentation and grow a system by always paying attention to your remote team members.

Do this correctly and you will have access to a disposable legion of the best engineers in the world. Imagine the power to have engineers come and go without them greatly impacting the business.

This section may come across as a somewhat counter intuitive, however the best teams I have worked with have not needed an office. From the perspective of a remote worker, offices encourage “encapsulated knowledge” a lack of visibility into office decisions and an inability to provide a meaningful impact to a business which results in poor morale and dedication.

The usefulness of thinking about your company as remote first lies in the way it forces you to create a self documenting organisation. Meetings can be run like webinars where the discussions are captured within the company discussion history. Standup should be held accessible to all timezones, using a microphone and should involve live updating project management software in realtime so people get a sense of where they fit in the big picture. Architectural change proposals and discussions can be documented within it’s own space in a repo. Ideally stored near the meeting video archive.

By thinking of your team as remote first you start adding an abstraction around office work that actually encourages better communication, accountability, architecture and community whilst at the same time avoiding some of the more toxic aspects of office culture.

Office time and time together is important and face to face meetings can allow for rapid communication but to leave remote workers out of the equation is dangerous for information flow.

Information putties up cracks

You are only as good as your poor performers. But why are your poorest engineers poor? Often junior engineers are considered poor because they lack experience. But what is experience but simply having access to high quality information about the consequences of bad and good decisions? It is precisely because they have not had great information that they make poor decisions. Fixing this information flow is key to supporting your team.

Teams with great information systems can control the rot and guide the inexperienced or wayward engineer back to the fold and encourage them to perform at the top of their game.

In summary

Your people are your most important asset in any organisation. They need the tools to do their jobs to the best of their ability and knowledge is the best tool you can arm them with.

Your team is your number one dependency the best thing you can do to keep them producing great output over an extended period is service them well with good systems to access and share information so they can produce the best possible outcome.

Your best chance at success will come when you:

• Hire the best people
• Talk about your code often
• Be judicious regarding technical debt
• Use tooling and constraints to communicate values
• Architect like you are short sighted
• Keep your organisation knowledge where your team will see it
• Use remote team members to foster documentation

Keep your team organised give them what they need to succeed and it should not be surprising when they do.

This article is a living document please reach out to me if you want to contribute or see anything inaccurate here.

You can follow Rudi Yardley on Twitter as @rudiyardley or on Github as @ryardley