Tag: Architect

Software engineering is often compared to well-established disciplines such as civil engineering. There‘s a problem with these analogies; unlike the very tangible products created by these traditional practices, software doesn‘t really exist. Not in the traditional sense anyway. Those of us in the world of ones and zeroes aren’t constrained by the same physical rules that bind classic engineering paradigms. While applying engineering principles to the software design phase works well, assuming you can implement the design in the same manner used by more traditional engineering approaches is unrealistic.

Both business and software are living, moving entities. Business requirements change rapidly due to things like newly acquired business partners and marketing strategies. This makes it very difficult to approach a software project in the same manner as a traditional engineering pursuit such as bridge construction. It is highly unlikely that you’ll be asked to move the location of a bridge halfway through a construction project. However, it is very likely that the acquisition of a business partner will require you to add support for organization-based content management to an application. This comparison should put things into perspective. We often say that software architecture decisions are difficult to change but not nearly so much as things that are literally and figuratively set in stone.

Knowing the products we build are pliable and that the requirements surrounding them are likely to change puts us in a different position than someone building an immovable object. Engineering endeavors of the physical flavor are much easier to implement in a “plan the work, work the plan” nature. With software things need to be tackled in more of a “plan the work, massage the plan” fashion.

These differences aren‘t always bad news, at times they can be advantageous. For example, you’re not necessarily constrained to building the components of a software system in a specific order so you can tackle high-risk issues first. This is in direct contrast to something like bridge construction where there are many physical limitations surrounding the order in which tasks are accomplished.

However, the flexibility of software engineering does present some issues, many of which are self-imposed. As architects we are very aware of the “soft” nature of our craft and we like to solve problems. Worse yet, the business owners are vaguely aware of these facts. This makes it easy for them to push big changes. Don‘t be too eager to accommodate large architectural changes just because it appeals to your solution-providing nature. Decisions like that can break an otherwise healthy project.

Remember that a requirements document is not a blueprint and software doesn‘t really exist. The virtual objects that we create are easier to change than their physical world counterparts, which is a good thing because many times they‘re required to. It‘s ok to plan as though we‘re building an immovable object; we just can’t be surprised or unprepared when we‘re asked to move said object.

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.