The Young Buck
This post belongs to a small series of posts. The main post is Heroes.
In this post, I’ll elaborate on what I identify as the Young Buck pattern. With my Wild West metaphor in mind, with the Young Buck I refer to the image of the young gunslingers that are just leaving home, stepping out into the big world. Usually, they are still full of high ideals and have a simplistic sense of justice. Unfortunately, their lack of real-world experience sometimes lets them get played for a fool. If they aren’t careful they might end up doing all the fighting and taking all the risks while someone else reaps the benefit from their efforts. Their simplistic, direct worldview could result in an ending which isn’t what they had in mind or hoped for. The townspeople might not be so pleased with the wreckage and carnage lying in the young bucks wake. The results of their hard battles may very well be that they end up getting scorned and even chased away by the very people they were fighting for.
Young Bucks see themselves as a hero, or they aspire to be one. Their eagerness to make it in the Wild West, to become a hero, can make them vulnerable to being used and doing someone else dirty work. A third party with a get-rich-quick scheme might misuse their sense of heroics for their own gain. Even without a third party encouraging them into heroics, their eagerness to become a hero, combined with a simplistic view of the world, might lead them down a violent path. They don’t realize yet that violence isn’t always the answer and should be a last resort. The townspeople might get some heroes, but run the risk that their town get’s destroyed.
Young Bucks in Software Development
Now how does this Young Buck metaphor relate to software development? In the software world, I have started labelling this ‘Young Buck’ pattern in a consulting context. It seems to be the business models of some large firms. Grap the young developers, with little to no experience, first job in a consultancy firm, company car included. They are the ones that are the easiest to convince by management that they need to put in extra time, work hard, stay late, work on the weekends, … All in order to make that big deadline. Personally, I’ve seen this happen the most on fixed-prize waterfall projects, that was bound to fail from the start. Yes, people still do big waterfall projects. Remember Obamacare? 1 )
Besides a fear of saying no to their manager when they are asked to work late/fast, there is frequently also a sense of misplaced pride that drives the Young Bucks. They are doing this hard work, rushing from deadline to deadline, Look at us working hard, getting things done. Our company and customer will be so proud of us. We’re playing with the big boys now…
It is precisely that sense of taking pride in doing ‘heroic’ deeds that categorize them as the Young Buck. Other than being someone who is simply being exploited. They can even have a sense of professionalism that drives them. Going the extra mile. The goal justifies the means.
The Young Buck hero was for me what Sandro Mancuso discussed in a very recognizable way in chapter 5 of his book The Software Craftsman 2. Even though he doesn’t call it that. Because being a hero may make you feel good about yourself, give you the sense that you are saving the day, that you are one of the hard workers, one of the professionals…
Age does not matter
Now, of course, you don’t have to be young to be a Young Buck. But it certainly helps ;) I’ve also seen many ‘older’ software developers participate in yet another project with crazy arbitrary, deadlines. The Young Buck pattern is not really age-related. Although I would hope that having seen the results of all those crazy deadlines one starts to realize that perhaps this isn’t in the best interest of the customer and the software. Then again if everyone around you acts like this is normal and that is the way we’ve always done it. It can be hard to get rid of the heroic aspirations.
The 7 most expensive words in business are: “We have always done it that way!”’ – Catherine DeVrye 3
There are of course also plenty of experienced developers that are no longer motivated by the pride aspect. They are doing it because it pays the bills or because it advances their career. Then there is then no more heroism involved. Or passion for that matter.
The software consultant world is where I have personally experienced and have been a Young buck myself. But the heroic driver can of course manifest itself everywhere. Start ups come to mind for example. Being the hero, making it happen, is a feeling that is defintely present there as well.
Consequences of Young Bucks
Now what are the consequence of the heroic actions of a Young Buck? They impact all parties involved.
Consequences for the Young Buck
The impact of these heroics for the Young Bucks, besides the possible negative impact on their social life, is the risk of a burnout. Combined with the risk of becoming disillusioned with the software industry altogether. Which I must admit, even when the ‘young’ part has long faded into oblivion, is hard not to succumb to. But that is a different story altogether.
There is a benefit to all of this for the Young Bucks. It is called experience. If they were paying attention they will learn how not to run a software project. Why best practices of software design are considered best practices. This experience is worth a lot. But it is unfortunate that it goes at the expense of the software and the customer.
Some Young Bucks won’t need to wait until the projects are done to reap the benefits of their experience. If circumstances allow it, and they rise to the occasion, some Young Bucks can grasp an opportunity to gain a bigger voice in the project. If they are given the chance they might even be able to do some great things with their short experience. Avoiding the negative backlash from yet another low quality or even failed project, helping to turn the ship around in time. They are able to cash in on their experience quickly. Which will benefit the Young Buck, customer and software. But this is not always easy. It requires the willpower to stand up to people, make oneself be heard, to take more responsibility. The Young Buck will try to improve the situation they are in. And in effect no longer be a Young Buck but evolve into a reliable professional. Regardless of their age.
Consequences for the software
Even if the deadline is met the customer is probably left with very poorly written software with a high maintenance cost. I mentioned Obamacare4 earlier, but I could of course mention a lot of Belgian projects as well. The Young Bucks may feel like heroes while they are rushing for the deadline, doing quick fixes, patch job after path job in production but in the long run it is the software that suffers and the customer that will overpay for a low-quality product. Because it is more important how a job was done than that the job was done. Because as we all know, software always changes and is never ‘done’. And that is a good thing.
There should be life possible for the software after a deadline.5
Consequences for the Customer
Often it is the customer who is the cause of the pressure. When combined with the idealism of the Young Bucks and lack of competent management this will result in very low-quality software. Which the customer has paid for. They paid for a Ferrari and received a bicycle edge in stone.
This has a much lower probability of occurring if the rate of Young Bucks is low. Because when the developers working on the project are concerned with the longtime value of the software instead of the short-term fame of making a deadline then the customer benefits. Leave your pride out of it and communicate honestly.
Pressure + Heroics + Requirements = Expensive Bad software
Consequences for the boss
Often the only one who benefits from these heroics is the Young Buck’s boss. The boss is the one that gets paid by the customer for the work and overtime. Of course, a bone will be thrown occasionally towards the ones doing the actual work. But it isn’t the boss that is working on the weekends, pulling an all-nighter, sacrificing their social lives.
Once sufficient deadlines have passed and the software goes into maintenance mode this is even more beneficial for the boss. The customer is still in need of software engineers to maintain and possibly extend the delivered software. Which takes more time than it should due to the numerous shortcuts that were taken. The Young Bucks are left maintaining the software and hopefully cleaning up a bit of the large technical debt they created themselves.
And the boss gets richer.
To those Young Bucks out there, who are in their first rodeo, Let me make it clear that working hard, no matter what, does not make you a professional. Not even if you ‘reach’ the deadline by working 16 hours a day.
Heroics shouldn’t come into play, heroes should not be necessary, the day should not need saving.
As someone at the start of their career, finally playing with the big boys, working on really big and important projects, it may seem perfectly reasonable to work hard from deadline to deadline. No more time for academic discussions. The customer wants it now! This is the real world!
Don’t kid yourself. Don’t allow others to give you a sense of guilt because you aren’t there working with them on that crazy deadline. While it looks like a heroic thing to do, it is actually a stupid thing to do. As ‘heroic’ things often are. It would have been much better if the heroics were never necessary. That the job was just predictable steadiness, without any heroic battles…
Being a Young Buck is in itself not ideal, it is not something you want to remain for the rest of your career. But it is also not a disaster. It is in fact normal when you don’t have much experience yet. The danger lies in being exploited, or mistake your sense of heroics for professionalism. The ideal situation would be that Young Bucks finds themselves under the safe, constructive mentoring of the more experienced software engineers. So that their desire to work hard and do a good job get’s channeled into the right direction. For this one needs to have a deal of luck to end up in such an environment. Because it is still the Wild West out there in the software world.
The time for heroics
Of course, sometimes things can still go wrong in production or an urgent intervention can be needed. But this should be an exceptional case. When it does happen, it should be dealt with swiftly. With a thorough post-mortem so we can learn how to avoid it in the future, making sure this does not happen again. Because we don’t want to let the exceptional become the norm.
Deadlines are prevalent in our industry. But while a real deadline can exist (one of the business requirements, GDPR for example, not an arbitrary deadline a manager cooked up to impress someone) the scope should be changeable. If something can’t be done, it can’t be done. Sleep and time off is a required attribute for quality software. The time that a given deadline scared or impressed me personally is long gone. It should still be business as usual.
If you can’t make a deadline with proper, disciplined work, then you don’t want to ‘make it’ with chaotic, sleep-deprived work.
For a Young Buck it may seem that working hard, making deadlines, saving the day is doing the right thing. But seen from a distance it is just another software mess under construction. Delivering low-quality software and potentially causing a lot of damage to the firm. Luckily just like with young cowboys, if Young Bucks survive the battles then after a while they might become experienced gunslingers who won’t fight a needless fight, don’t get played for a fool. They might become reliable professionals.