What Makes a Great ... (part 1)

What Makes a Great ... (part 1)

[dropcaps round=”no”]A[/dropcaps] 4-part series about the attributes of great software developers/architects.  See part 2 here.

A great software developer is someone who;

  • Produces great code  on time
  • Utilizes clean and simple architectures and designs, preferring simplicity over complexity
  • Is a good team member and helps others succeed
  • Lives on Mountain Dew, never changes clothes, sleeps on the couch in the office

The attributes associated with such a software developer are:

Humility, Intelligence, Teamwork, Responsibility, Creativity, Precision, and Ability to Prioritize

Beyond the great developers, there are two types of very good software developers;

  1. The great team member/communicator. They not only produce very good code  and clean architectures, but they are also an invaluable team contributor and help everyone around them to be better.
  2. The great coder. He/she produces great quality code at exemplary speed, utilizes the correct architecture and design patterns, but is not a great communicator or team member.

The true measurements of a great software developer are their product output and their team contributions. In my experience he/she requires a combination of the attributes listed above to consistently make those contributions. What if the developer is missing one or two of those attributes? He/she may still be a good to great developer, but will most likely not be one of the best because a key attribute is missing. There are always exceptions, there can be the genius who does not work well with others, but comes up with amazing architectures. That person may traditionally be considered a great software developer/architect, but only under specific circumstances and on the right team.

We have all met SuperGeek, yes, he/she who thinks they are the best at coding in Z-Perfect. SuperGeek will tell you that no other language can compete with Z-Perfect, in fact, before he/she came along, noone had accomplished anything, ever. If you come across SuperGeek; nod politely, excuse yourself for more food/drinks/bathroom breaks and thank your lucky stars that you do not have to work with SuperGeek, because some poor person(s) does. While you are at it, have a drink for said poor person(s), but not if you are driving, flying, operating heavy machinery, performing surgery, debugging code or; are or plan on participating in any other risky activity.

Not everyone can be a great software developer and there is still plenty of room for the good to very good software developers. A team with good software developers and a great software developer who continually contributes to and improves the team is going to be highly successful. The advantage of the very best developers is that they make everyone around them better.
Before we go into each of the attributes and why they are important, we should first discuss most people’s measurement of a great developer, the code output. While some may claim that they can measure the quality of code through software or by adhering to a certain ‘way’ or pattern of development, the truth is much grayer. If you are a developer, take a look at code you wrote 2 years ago, did you consider it to be high quality then? What about now, does it still hold up? There are so many factors to determining code quality that it becomes very difficult to analyze quantitatively. Some factors are;

  1. How quickly was it produced? How does that compare to similar projects (by feature points, story points, etc.)?
  2. How many bugs where discovered in relation to project size/complexity?
  3. How difficult where the bugs to find and fix? How severe where the defects? How complex where the defects?
  4. How easy is the code to maintain? Does maintenance require experts or can an average coder perform maintenance?
  5. Does the code meet performance criteria and/or perform adequately for its intended task?
  6. Does the code scale?
  7. How documented is the code? Is it self-documented through good use of variable/function names or does it require additional documentation?
  8. Is the architecture appropriate for the task? Is it as simple as it needs to be and/or can it support anticipated future requirements?
  9. Is the design pattern appropriate?
  10. Do the unit tests cover a high percentage of the code? Do they cover negative and positive assertions, exceptions, and a variety of potential inputs?
  11. Is the code easy to refactor?
  12. Is the mix of Modularity vs Extensibility vs Complexity appropriate?
  13. Did it meet its time to market and quality goals?

I am sure there are many other factors also, but the gist is that there are many implementations that will meet the stated criteria of a project, but how you meet that criteria is often as important as completing the project. Very few projects have zero maintenance, updates, or support. A great developer understands that and can determine the trade-off between various decisions throughout a project’s lifecycle. A great developer can also rely on prior experience to predict likely problems in the near-term and proactively implement solutions ahead of time, while not overcomplicating the project. While many programming paradigms dictate implementing only what is needed today, great programmers have the knowledge and experience to understand when something more is appropriate.

Great developers understand many of these factors (and probably more). He/she knows that their code will never be ‘perfect,’ and at times, it may not even conform to common rules/patterns or best practices. Great developers know that in order to deliver a project you often have to compromise, and in order to compromise effectively, you have to know what the priorities are. An example from my past is that in 2005 I was looking at implementing AOP in C# to alleviate some routine work (logging, exception handling, basic CRUD). At that time, there wasn’t a production ready IL post-compiler, so I looked at using some .NET infrastructure. A quick performance test yielded a surprising 10x performance penalty that was not acceptable. Instead I built a framework for some of the features, and for others we created common patterns and best practices. AOP would have been much cleaner and very nice, but it would have gotten in the way of producing the right product. Later I contemplated using PostSharp, but held off due to the viability of the MVVM model in-place and the fact that a single IL-level bug could cost 10-100x more to fix than a simple C# framework fix. That equation depends largely on the team, the project and your testing maturity.

Another example; at Microsoft I worked with a very smart gentleman who use to work for NASA, writing code for the space shuttle. To call that code critical would be an understatement. Since it was in the 70s/80s, the entire code ran in 256KB. Due to processing and memory constraints they used a proprietary language and tools, very specific to the job. According to this very smart man rocket programmer/scientist, the team on average achieved approximately one line of production-ready code per day. That was the right decision for that project, but not many software projects can literally be fatal and cost Billions of dollars if they go wrong.

Compare that to the mobile app market. Apple launched the iPhone in 2007 (although Microsoft had ‘smart’ phones for years before that). Since 2007, over 1 million iPhone apps have been built, most being built relatively quickly, for low cost, and hence of low quality. Time to market is often the most critical aspect; quality and testing are not seen as fundamental. In fact, try to outsource an iPhone/Android app and see how many outsourcing companies include any actual testing (other than developer testing). One can argue if it is the right approach, but the fact is that if companies built apps like NASA programmed the shuttle, neither the iPhone nor its apps would exist.
Up Next… What makes a great software developer/architect, Part 2 – Humility, Intelligence