WTF is a Balanced Developer
When working in a team trying to get a new version of the company software out the door in a timely manner while also ensuring all of the features are done and everything passes QA is a challenge. Many teams will cut certain features to hit the deployment or will sacrifice a bit of quality and log some bugs just to get everything deployed. At what point do you call an audible and get everything done right?
This is where teams, specifically developers; need to strike the right balance between being effective and being efficient. One does not equal the other.
The Effective Developer
We all want to be this person; the code is clean, has already been refactored, can scale, has documentation and unit tests, and does everything it was designed and required to do. This is the goal for many and can lead to bonuses, pay increases, and possibly promotions.
But, how long will all of this take?
The effective developer will review all of the documentation in the requirements including mockups and will hold meetings to discuss any hidden gotchas that the business analyst (BA) or product owner (PO) didn’t think of. They will take their time to make sure that everything from every angle is considered, documented, and that everyone is on board before writing a single line of code.
This is akin to the story of the axe man competing with another to cut down a tree. The competitor chops their tree down in 4 hours while the other sharpens his blade for 3 hours and chops his down in 1 hour (something like that). They both spent the same amount of time, but one of them was more effective at chopping down the tree with a lot of preparation.
Another analogy would be the tortoise and the hare… slow and steady wins the race. But what happens when the race is time to market and the more time you spend meeting, discussing, arguing, documenting, revising, etc is what denies you from beating the competition?
Consider this on a larger scale where the count for the development team, including BAs, POs, UX designers, and QA can be upwards of 100 or more. Even with an Agile methodology approach, the effective team will still need more time to deploy.
The Efficient Developer
Oh look, we all wanna be this person too. There’s no time or need for a bunch of meetings, code documentation, or unit tests as you’re smart enough to read what the code is doing and there’s a QA team to check the quality of the work. You have to get the product updates completed quickly, log whatever bugs come up during testing, and deploy. Any changes to the requirements are verbal and agreed on by everyone.
You beat the competition to the market and dominate the space which leads to bonuses, pay increases, and possibly promotions. Oh, look again; the same benefits for being an efficient developer.
The efficient developer does not want to waste effort on getting every little detail discussed, resolved, and documented. They will much rather get to work and the refinement can be done when they get to that part of the project or in another release.
There’s a story of a class that was divided into two groups; both groups were tasked to grow the best, biggest, and most fruitful tomato plant. One group started working on their plant and worked on every detail from the soil, amount of water and light, and variety of seed. The other group worked on trying all sort of growth experiments. By the end of the experiment, the first group, being effective, had one big and beautiful tomato plant with big tomatoes. The other group, not only had the same as the first group but, through their process of efficiency, had more plants with different varieties of tomato and even created a new variety.
When the first team (effective team) failed, they reviewed what went wrong, corrected their mistake by changing one parameter at a time, and tried again. When the second team (efficient team) failed, they learned from it quick and moved on, and found what worked with all sorts of parameters; they also had other plants growing at the same time, so their failure was just a learning experiment.
The Balanced Developer
And, here’s what we all really want to be. If Waterfall SDLC and Agile Methodology got together and had a baby, it would be “The Balanced Developer.”
“Research your own experience. Absorb what is useful, reject what is useless, add what is essentially your own.” — Bruce Lee
There are pros and cons to the old Waterfall method and the Agile method, but we won’t go into them. Instead, we should be taking what we’ve learned from each (if you’re old enough to have experienced the Waterfall) and using it to our advantage. We certainly need a meeting or two, not 10; discuss only what is the minimal viable product (MVP), document, and get to work. You’re only working on so many features for this release and will have documentation for QA and to show the progression of the application.
Naming conventions should be simple enough in your code that it doesn’t require code documentation. Unit tests are a great thing to have, but you don’t necessarily need one to test that a drop-down component works on every page of the application; test what matters (this will trigger some of you)… you have a QA team.
You’re not spending weeks or months gathering requirements and buy-in from everyone, you’re spending hours or maybe a couple of days. If everything for the MVP is documented properly and you have estimated the work out correctly, then you should have minimal to no bugs in the code and can respond to the market much faster; again with another MVP feature. This, of course, is the ideal situation and goal for every developer and every team; it’s also a work in progress as you try to find the right balance between being effective and efficient.
Final Words
For the most part, developers fall in the effective or efficient category, but rarely as “Balanced Developers.” This person is ideally going to take it upon themselves to educate the team, BAs, POs, and QA on what to look for when documenting requirements for an MVP and in doing so, help ensure the success of the team, the product, and the business. And, doing all of this does not mean you get double the benefits of bonuses, pay increases, and promotions; but it does mean that everyone benefits.
What are your thoughts on being effective, efficient, and/or balanced as a software developer?