Category: Software Architect

Putting together a team of outstanding developers is one of the most important things you can do to ensure the success of a software project. While the concept of keeping that team together does not seem to get as much lip service, it is equally important. Therefore, you need carefully select your development team and diligently protect it once assembled.

Most people probably agree that finding top-notch developers requires thorough technical interviewing. But what does thorough mean exactly? It doesn‘t mean requiring candidates to answer difficult questions about obscure technical details. Screening for specific technical knowledge is definitely part of the process but turning an interview into a certification test will not guarantee success. You are searching for developers with problem solving skills and passion. The tools you use are sure to change; you need people who are good at attacking problems regardless of the technologies involved. Proving someone has the ability to recite every method in an API tells you very little about their aptitude or passion for solving problems.

However, asking someone to explain their approach to diagnosing a performance problem gives you great insight into their methods for problem solving. If you want to learn about developer‘s ability to apply lessons learned, ask what they would change given the chance to start their most recent project anew. Good developers are passionate about their work. Asking them about past experience will bring out that passion and tell you what correct answers to technical trivia questions cannot.

If you have been diligent in staffing a strong team, you want to do whatever is within your power to keep the team together. Retention factors such as compensation may be out of your hands but make sure you‘re taking care of the little things that help to foster a healthy work environment. Good developers are often strongly motivated by recognition. Use this fact to your advantage and acknowledge stellar performances. Finding great developers is difficult. Letting people know they are valued is not. Don‘t miss simple chances to build morale and boost productivity.

Be careful with negative re-enforcement. Too much of it may stifle a developer‘s creativity and reduce productivity. Worse yet, it‘s likely to create dissension among the team. Good developers are smart; they know they‘re not wrong all of the time. If you‘re picking apart the minutia of their work, you‘ll lose their respect. Keep criticism constructive and don‘t require that every solution look like it came from you.

The importance of staffing your development team correctly can‘t be overstated. These are the people who do the heavy lifting. When it comes to estimates, they‘re all treated as equal producers. Make sure it‘s tough to crack the starting lineup and once you‘ve got a winning team go the extra mile to keep it together.

We build tools. The systems that we make have no other reason to exist (nor we to get paid) than to help someone, usually someone else, do something.

Martin Heidegger, an influential German philosopher of the 20th Century, explored the ways that people experience tools (and more generally “equipment”) in their lives. People use tools to work towards a goal and the tool is merely a means to an end.

During successful use a tool is zuhanden (“ready-to-hand”, having the property of “handiness”). The tool is experienced directly, it is used without consideration, without theorisation. We grasp the tool and use it to move towards our goal. In use, it vanishes! The tool becomes an extension of the user’s body and is not experienced in its own right. One sign of a tool being zuhanden is that it becomes invisible, unfelt, insignificant.

Consider what it feels like to hammer a nail or to write with a pen. Think about that immediacy. Think about the way the tool seems to be a seamless extension of your body.

Alternatively, and usually when something has gone wrong with it, the user may experience a tool as vorhanden (“present-at-hand”). The tool is isolated from the goal, it lies before us demanding attention. It becomes a topic of investigation in its own right. The user is no longer able to proceed towards their goal but must deal first with the tool, without it doing anything to move them towards their goal. As technologists we tend to experience the systems we build for users as vorhanden while we build them, and again when we receive defect reports. For us, the tool is quite properly an object of enquiry, of theorising, of investigation. It is a thing to be studied.

However, it is crucial to their success that the users experience the tools we build for them as zuhanden. Are your systems architected to be invisible in use? Does the user interface fall naturally to hand? Or do your systems keep demanding attention, distracting users from their goal?