Is there a rockstar in your development team ?


In software development, the performance difference between a good and an average developer can be in order of magnitudes, much more than any other field. In my experience, a good developer is at least ten times or more productive vs an average developer. The performance difference is even higher when there are poor developers in the team, since a significant portion of your good developer’s time is spent in ‘baby-sitting’ – insuring that the bad developer is writing acceptable code. If you want to have a quality product having developers with poor development skills in your team is not even worth it, since in the long-term the net gain will be negative like when you may have to go back and start from scratch. A rockstar software developer is someone who is even better than a good developer, and while rockstars do exist, finding one is quite a task.

Therefore, having a rockstar in your software development team is like having a precious diamond. Not only is the rockstar developer able to quickly build up new features in your products, he or she is able to guide and mentor other team members and motivate them to be rockstars one day. Unfortunately it is too easy to fall into the trap that if a developer is getting features out fast and is finishing tasks on time (or even before), she or he is a rockstar.



One of the fundamental problems with software development is the intangible and abstract nature of software. Unlike other undertakings like those in civil, mechanical and even electronics engineering, it is impossible to gauge the completeness of a product just by looking at it. Sure by watching a program execute you can check feature completeness, and by keeping an eye on metrics such a maintainability index and cyclomatic complexity you can get some idea on quality. However, a good working software with high maintainability index and low cyclomatic complexity may still hide a serious problem behind those pretty screens and cool features.

This serious problem is called ‘technical debt’ and it increases exponentially as new features are added. Everything works fine till the day the ‘debt collector’ comes calling, which believe me they do at some stage in any software. You know that day has come when the software edifice falls like a pack of cards after few lines of code change for a simple feature. Fixing the issue, opens up two new ones, fixing which opens up four and your commercial software doesn’t look that stable anymore. You are forced to devote more than 50% of the development/testing time for refactoring and smoke testing before releasing any product impacting revenue and growth, until the time you throw in the towel and start from scratch at a huge cost.

Managers and team leads will try to figure out what happened, after all you had some rockstar developers who wrote most of the initial code (Note that in most cases, the technical debt collector comes much after the rockstars have left the company). Due to the former rockstars you were able to make every release in time, made lots of revenue and paid the rockstarts 6 –figure bonuses. Hence, the blame will generally fall on your current developers who all seems to lack the magic of a rockstar. To fill the problem the tendency will be bring back some of the rockstars back as consultants and pay them hefty sums to fix the bugs. However, managers and leads should do this only after careful code analysis as this may exacerbate the problem and only postpone what is inevitable.

Looking at the code history throughout the lifecycle of the product will reveal the root cause of the problems, and it may turn out that your rockstars weren’t rockstars after all. While they did deliver all features in time, they took shortcuts which remained invisible to the non-coding world. Your initial design had classes without any inheritance or composition design (just so that you can claim object-oriented methodology, which sounds cool) and unit tests were written without full integration tests. Or things could be much worse, rather than refactoring existing routines the rockstar developers copy-pasted code and created new routines (btw, this is equivalent to a ‘felony’ in software development) and created new unit tests for these routines (this way all unit tests passed). Maybe there were no unit tests at all (a ‘felony’ too) leaving you no way to regression test your code changes.

Technical debt comes in other forms. To save time and focus on functionality no one added any comments, having some poor non-author of the code to use breakpoints and print statements (requiring countless hours) to figure out why your recursive routine is crashing into its 1000th call. Perhaps you did raise that point only to be told by the rockstars that code is the best documentation. Remember that code is the best documentation to only the people who wrote it, for others it’s just chaotic logic that without comments, takes valuable time investment to figure out.

All managers and team leads in software development need to remember that timely delivery of assigned tasks should not be the sole criterion in ascertaining a rock star. You need to have a formal code review process in place and should do some code reviews yourself to identify if you really have rockstar(s) in your team whom you can trust with. Apart from delivering required feature sets in time, rockstar developers constantly refactor the code, make necessary design changes and back up with good unit test coverage. Rockstar developers inherently feels uncomfortable in writing code that only meets the bare minimum, they realize the value of consistent design and do not shy away from making changes on their own initiative that will improve code readability and maintainability. A rockstar developer constantly improves her and his skills and looking at the code she/he wrote last year, thinks a better job could have been done. If you have such a person in your team, he or she is better than having ten or more average developers. Do everything you can do to retain them as there are worth their weight in gold.

Love or hate this post ? Have other ideas ? Please leave a comment below!

Comments

Post a Comment

Popular posts from this blog

Part III: Backpropagation mechanics for a Convolutional Neural Network

Image
In part-II of this article, we derived the weight update equation for the backpropagation operation of a simple Convolutional Neural Network (CNN). The input for the CNN considered in part-II is a grayscale image, hence, the input is in the form of a single 4x4 matrix. CNNs used in practice however, use color images where each of the Red, Green and Blue (RGB) color spectrums serve as input. Hence, a CNN with the inputs color coded with their respective spectrums look like: In this article we expand upon the original CNN where the input is represented by 3, 4x4 matrices each presenting the pixel intensities for the RGB color spectrum. Hence is we represent each of the pixels with the CNN given is represented by: In this CNN, there are 3, 4x4 input matrices, one 2x2 filter matrix (also known as kernel), a single convolution layer with 1 unit, a single ReLu layer, a single pooling layer (which applies the MaxPool function) and a single fully connected (FC) layer. The elements
Read more

Introducing Convolution Neural Networks with a simple architecture

Image
Convolution Neural Networks (CNNs) are different from standard Neural Networks (NNs) as their input is 2-dimensional vs. 1-dimensional in a standard neural network. While the underlying principles between CNNs and NNs are same, CNNs do introduce some new concepts. In this article, we take a look at how CNNs operate using a very simple CNN architecture, given below. In this simple CNN, there is one 4x4 input matrix, one 2x2 filter matrix (also known as kernel ), a single convolution layer with 1 unit, 1 Rectified Linear Unit (ReLu) layer with one unit, a single pooling layer and a single fully connected (FC) layer. The elements of the filter matrix are equivalent to the unit weights in a standard NN and are updated during the backpropagation phase. Real-life CNNs are significantly more complex than this with several repeating layers of convolutional, ReLu and pooling layers forming a true deep learning network. All the matrix dimensions are also magnitudes higher to represent hig
Read more

Deriving Pythagoras' theorem using Machine Learning

Image
In an earlier article which introduced machine learning, we had seen a comparison of equations derived from scientific principles vs. those derived via machine learning. In this article, we will see how Dythagoras a citizen of the far away planet Darth in the Dilky Day galaxy uses machine learning to derive a correlation between the length of 3 sides of a right-angle triangle. Dythagoras - resemblance to Pythagoras not intentional Unlike humans, the citizens of Darth (Darthians) are not very bright mathematically but are capable of observations and making tools. They had been handed a computer and the Dasmic machine learning library by human astronauts of a SpaceX expedition who had visited them a few months ago. The citizens of Darth need to shorten the travel time between 2 of their biggest cities of Aville and Cville. Currently the only way to goto Cville from Aville is via Bville that takes several hours. Darthians need to know the direct distance between Aville and Cvill
Read more