- Devotion and Knack for Design and Architecture
I am a strong advocate of refactoring throughout the lifecycle of a product. However, the cost of "fixing" a poor design can be very high and increases over time. It is always a good idea to do some level of design and architecture up-front, before any coding begins. There is a great deal of literature available on the benefits of good design that essentially boil down to software that is of higher quality, is easier to maintain, and has the flexibility to change over time. I believe it 's a mistake to think that Agile development precludes design and architecture. It is still important to include design and architecture in your agile processes. This may be a topic for a future post.
One example of something that must always be carefully considered is public interfaces. If your software project has a public-facing API, changing this API after release has a major impact on your customers. Of course you can version your APIs, but you will still be left supporting the old APIs for a long time, if not indefinitely. Poorly designed APIs can, thus, severely limit the growth and architectural flexibility of your code.
Bear in mind that software often lives in the field much longer than originally anticipated. I like to multiply the expected lifetime of the software by at least two when considering how much attention should be given to design. Often times the end goal of a project is a prototype. Obviously for prototype work design is less important. Resist the surprisingly strong pull to allow a prototype to morph into a customer-facing product. If you work in an organization where prototypes frequently turn into product due to forces outside your control, you may need to start putting more design into your prototypes.
Lastly, while it is always more costly to do too little up-front design, there is also a cost of devoting too much time on design. This is a balance discussed in a future topic.
- Attention to Quality
This item speaks for itself. Apply modern coding techniques, and always remember the KISS principle. The highest quality approaches over the long-term are almost always the simplest approaches. Be an advocate for quality and simplicity within your team. As Hal Ableson and Gerald Sussman famously wrote, "Programs must be written for people to read, and only incidentally for machines to execute."
If you can't pick up something you wrote 3 months ago and understand what you wrote, chances are that code is also buggy. Two simple rules for code support that I find have the biggest impact are:
- Name every method and class precisely
- Decompose your methods as much as possible
These two techniques alone will make your code easier to read and understand.
Ensure quality through integration and unit tests. Measure test coverage and monitor tests frequently, if not with every checkin. Consider adopting a Test-Driven-Development(TDD) approach.
- Relentless and Effective Communicator
I find that face-to-face communications are always the most effective, but are not always practical, particularly with geologically diverse teams. Don't be afraid to hold meetings to discuss important design decisions, but don't waste people's times with frivolous ones. Pay attention to your attendee list. Invite all the stakeholders, but resist the urge to expand beyond that. If the list with stakeholders exceeds 5 or 6, consider if a smaller number of stakeholders would work better, and then later follow-up with the other stakeholders on the proceedings.
Where face-to-face is not possible, use video or phone. Next on my list would be instant messaging. Email tends to be one of the least effective means of communication. A good tactic to deal with an email chain greater than 5 or 10 replies is to setup a meeting to resolve the issues.
Being a leader does not mean directing everyone on the team on every aspect of design and coding. Recognize that there are many strong developers on your team and that everyone's view is valuable. The best leaders have well-respected voices in the discourse, providing strong influence on the group, not dictating to the group. Often others on the team have better or more practical solutions. A good leader will actively recruit other opinions on important matters and be quick to support good ones that are superior or equal to his/her own preconceived notions of solving the problem at hand. Many of us in software design have strong egos. I actually think this is important, because with ego comes confidence and a higher participation level. Be careful not to trample on others' egos and be careful to keep your own in check.
This extends even more importantly to cross-group communications. Always get input and buy-in from members of all affected teams on any decision which impacts or involves them. The best solutions tend to be the ones developed with a small group of people with differing backgrounds. There is no easier way to hit late roadblocks than to make a decision without including a major stakeholder.
