StreamHacker Weotta be Hacking

Programming As Information Architecture

Code = Information. [1] Therefore, Software Architecture can be approached as Information Architecture. Information Architecture can be defined as

1. The structural design of shared information environments.
2. The art and science of shaping information products.

The above definitions and much of the inspiration for this article comes from the book Information Architecture for the World Wide Web. My goal is to explain some of what an Information Architect does, and that software developers, especially the lead developer, should approach their code as an information system, applying the principles of Information Architecture. Why? Because it will lead to more organized, better structured, easier to understand code, which will reduce maintenance costs, decrease training time, and generally make it easier for you and your team to get things done.

So, what are the core focus areas for an Information Architect?

• Organization Systems
• Labeling Systems
• Navigation and Search Systems
• Controlled Vocabularies and Metadata
• Research
• Strategy
• Design and Documentation

Organization Systems

Organization Systems are exactly what you think they are: systems to organize information. Imagine if you had to come into your current code base completely fresh, knowing nothing about it. Does that thought horrify you? If your code isn't organized, then it can be very hard for new developers to come in and figure out what's going on. Think of your code repository as a shared information environment. If you are the only one that can navigate it, let alone modify it, then you'll always be stuck maintaining it. Hopefully your goal is not job security, but to provide an environment conducive to change.

So how should you organize your code? Unfortunately, that's not something that's really taught anywhere. My general practice is to follow the recommendations of the language/platform. If they say all code should go in a directory called src/, then that's where I put it. If every class is supposed to be in its own file, then that's what I do. And if the platform documentation doesn't specify how to do something, I'll find a major open source project and see how they do things. The key to an organization system is to maintain logical consistency. Then, as long as you know the logic, you can figure out where things are or where something should go.

Labeling Systems

Labeling Systems are basically standard naming practices. In IA, a labeling system specifies what label goes with each element in every context. For programming, you'll want a consistent naming scheme to make sure the all your code objects are consistently and clearly labeled. Good labels are simple, make sense in context, and hint at the details of the labeled object. The goal is to communicate information efficiently. You are not just writing code for yourself, you're writing code for the team. The best code is not only functional, it's readable, concise, and even beautiful. Clear labeling goes a long way towards achieving that ideal.

Navigation and Search Systems

Navigation and Search Systems are very important to information focused websites, but they don't apply much to code by itself. However, good Navigation and Search Systems are essential for API documentation. I believe that the quality of the API documentation has a huge effect on the adoption rate of libraries and platforms. [2] Good API docs can be great resource for quickly looking up a function and understanding how to use it. But if a developer can't navigate and search your API documentation, then how will they figure out how to that function works? Luckily for us programmers, navigation is usually provided for free with a documentation generator. And google can handle the search for you.

Controlled Vocabularies and Metadata

While all programming languages have a controlled vocabulary, in IA this refers to domain knowledge. The principle is to use words and jargon that are common to whatever domain you are developing for.

Metadata, in this case, is information about the code, such as comments and documentation. Just as an Information Architect is in charge of the language use within a system, the lead developer should be in charge of the domain language and how to use it.

Research

The goal of IA Research is to understand what needs to be designed and built before doing the work. In programming, you are often presented with problems you've never solved before. Hacking, or exploratory programming, is a way to figure out and evaluate possible solutions. Hacking is Research. The goal of research oriented hacking is to figure out possible solutions, evaluate platforms and technologies, and understand the constraints that come with each technology and solution. The knowledge you gather from research is used to drive your strategic choices.

Strategy

IA Strategy is about platform, process and design. What programming language(s) will you use? What are the core design patterns and architectural choices? What version control system will the team use? How will you track progress? Your strategic decisions will set the design constraints of the implementation and drive the development process.

Design and Documentation

In software development, the code is the design, but not everyone will want to read your code to understand how things work. You may need to communicate the design in other ways, such as with diagrams, comments, and documentation. And if the code is being written by someone else, then it's your job to communicate how their code will fit in to the rest of the system. Design documents aren't for you, they're for the other people on the team. You do want other team members to understand your code, right? And if your diagrams and documentation are good enough, you might even get business people to think they understand your software too

Conclusion

Information Architecture provides a top-down view of your software system. As a lead developer or software architect, IA principles and practices can help make sure that your system is well designed and that the design is communicated clearly to all team members. For further reading, I recommend Information Architecture for the World Wide Web and Documenting Software Architectures.

Notes

[1] Code = Data, Data = Information, Code = Information.

[2] I wish I had some data to back this up, but it's certainly how I behave. Lack of clear documentation = fail.