200 OK SwatantrAI

97 Things Every Software Architect Should Know – 4/97

All too often software architects sit in their ivory towers, dictating specifications, technology decisions, and technology direction to the developers below. More often than not this leads to dissension in the ranks, quickly followed by a revolt by the masses, finally resulting in a software product that doesn’t even come close to resembling the original requirements. Every software architect should know how to communicate the goals and objectives of a software project. The key to effective communication is clarity and leadership.

Clarity describes how you communicate. No one on your team is going to read a 100 page architecture decisions document. Being clear and concise in the way you communicate your ideas is vital to the success of any software project. Keep things as simple as possible at the start of a project, and by all means do not start writing lengthy Word documents. Use tools like Visio to create simple diagrams to convey your thoughts. Keep them simple, for they will almost certainly be changing frequently. Another effective means of communication is informal whiteboard meetings. Nothing gets your ideas across better than bringing in a group of developers (or other architects) into a room and whiteboarding your ideas. Also, be sure to always have a digital camera with you at all times. Nothing is more frustrating than being pushed out of a meeting room with all of your ideas stuck on a white board. Snap a picture, download it, and share it via a wiki to the rest of the team. So throw away the lengthy Word documents and focus more on getting your ideas across, and afterwards worry about recording the details of your architectural decisions.

One thing most software architects fail to realize is that a software architect is also a leader. As a leader, you must gain the respect of your co-workers to work effectively in a healthy and effective environment. Keeping developers in the dark about the big picture or why decisions were made is a clear recipe for disaster. Having the developer on your side creates a collaborative environment whereby decisions you make as an architect are validated. In turn, you get buy-in from developers by keeping them involved in the architecture process. Work with developers, not against them. Keep in mind that all team members (e.g. QA team, Business Analysis, and Project Managers as well as developers) require clear communication and leadership. Employing clarity and effective leadership will improve communication and create a strong and healthy work environment.

If “Communication is King” then clarity and leadership are its humble servants.

97 Things Every Software Architect Should Know – 3/97

Right now someone’s running a failing project to build a payroll system. Probably more than one someone.

Why? Was it because they chose Ruby over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We’ve all seen the technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn’t up the the task?

Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about what it takes to help make those people successful.

Equally, there’s a good chance that there’s someone who you think is “just not doing it right” and is undermining the project. In these cases, the technology you need to solve your problem is very old and well established indeed, in fact it’s possibly the most important technical innovation in the history of humanity. What you need is a conversation.

Mere familiarity with the conversation as a technology isn’t enough. Learning to treat people with respect, and learning give them the benefit of the doubt, is one of the core skills that turn a smart architect into one an effective architect.

There’s lots more to it than this, but a couple small tips can significantly increase your conversational effectiveness:

1) Approach these events as conversations — not as confrontations.

If you assume the best about people and treat this as a way to ask questions you definitely learn more, and you are less likely to put people on the defensive.

2) Approach these conversations only after you’ve got your attitude right.

If you’re angry, frustrated, annoyed, or otherwise flustered its very likely that the other person will interpret you non-verbals as indicating that you’re on the attack.

3) Use these as opportunities to set mutually agreed upon goals.

Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people’s participation. Explain that some people are more introverted and need longer silences before they jump into a conversation, and ask if they will help you out by waiting 5 seconds before jumping in.

If you start with a shared purpose, treat people “problems” as an opportunity to learn, and manage your own emotions, you’ll not only become more effective, you’ll also discover that you learn something every time.