One of the key features I like about Agile estimation is that the members on the deliverable side get the final say regarding the size of work. Traditionally, I’ve been a part of Fibonacci numbers, though I’ve heard some excellent arguments for T-shirt sizing (no surprise – finance wants to correlate everything to man hours for tax deductions, but this an outside interest which shouldn’t interfere with the estimation process itself).
Has anyone been part of a project estimated by a singular entity that’s not writing code? It can be extremely frustrating. It’s funny – the younger developers think it’s a problem unique to them – but the older developers have “seen it all”. I had a great conversation with an older, ex-C++ developer, and we brought up The Mythical Man Month. If you’re not familiar with Brooke’s law, it states something to the effect of “adding manpower to a late software project makes it later”. I say that because the book is on my list of reads, but I technically haven’t read it yet. I notice some companies believe that any problem can be solved by throwing more manpower at the problem, without any regard to the quality of the product or developer skill/mindset.
There’s something about the “McDonald’s Developer” that irks me. The idea that I can snatch up any Joe off the street, and in a handful of hours, teach him how to flip a burger and write code. What’s so difficult for me to reconcile about this issue, is that McDonald’s (and most fast food chains) are among the leanest businesses in the world. They have to be – fast food is fiercely competitive. My Lean/Six Sigma brain wants to agree – but my pragmatic developer brain can’t seem to understand how this results in a high quality, maintainable product. Developers who tend to fit this profile think of their problems in terms of for loops and making sure they check for null. They haven’t had enough time in the industry (or around better developers) to look at architectural concerns, proper structuring of code to follow SOLID principles, and constantly analyzing what they write to find cleaner, most readable and efficient patterns. This primitive skillset is then propagated by higher ups who don’t see the benefit of empowering these new developers, or simply don’t know how to grow the potential of a junior member. Outsourcing has had a detrimental effect on this situation, as that mentality feeds the idea that more asses in chairs will solve your problem, when the truth is a good development team will design a system such that some obstacles will never even arise. Boy, that makes it difficult to claim a victory for solving a problem by preventing it. Anyone who’s ever worked in quality or been around manufacturing would understand all too well.
I think part of the way that I reconcile this McDonald’s mentality is that the architecture and framework of your application(s) should make it difficult for poorly designed or written code to enter the system. This hearkens back to the mistake-proofing idea in Lean. The process itself should be set up to minimize risk for any negative factors. There are more than enough design patterns which make it easy to reason about the structure of a system without having to dive into thousands of lines of code. It’s not that McDonald’s employees are any less capable or intelligent – it’s that the process sets them up for success and makes it difficult for them to mess up. I’m allowed to make commentary here, having worked part-time in retail food myself.
Coincidentally (or not), I’ve noticed that places where the outsourcing mentality are prevalent have little to no code review practices – does that say anything about their value for their internal customers?
Starbucks is another example of treatment of internal customers. It’s pretty obvious their culture attracts certain types of people (if not stereotypical). It’s a very similar corollary – the processes they have in place make any given drink virtually identical, no matter who makes it, or where.
Does this mean their employees, who are part-time, single digit hourly wages, are any less deserving of investment?
Not at all! In fact, I have a few friends taking advantage of the Starbucks education benefits and wrapping up their undergraduate degrees. They may or may not be with the company in 5 years, but then again – most tech professionals won’t be either! Costco is a good example of a company that is well known throughout Wall Street as investing so heavily in their employees that they have the best employee retention and customer satisfaction rates.
As I explore this idea more in the future – I’ll be sure to write my new discoveries on it. In addition to the the rush I get from refactoring badly written C#, mentoring newer developers is near the top of my list of favorite things to do. And I have a feeling that if they feel invested in, and are growing their skills, it’ll reduce the dollar and time waste involved with maintaining the revolving door of new hires.
I’ll have to end today’s post with a song of the same name. Sublime, whose title album went five times Platinum largely due to the success of “What I Got,” has a very college reggae/party ska feel, which tends to be a very specific taste. I always felt their music was fun, but not something I could commit to buying a physical copy of, or listen to repetitively and recommending to others. What I didn’t know, is that their frontman, Bradley Nowell, died in 1996 – and the band dissolved soon after.
Turns out, they reformed with a new frontman in the late 2000’s – and it’s awesome. The new singer/guitarist is Rome Ramirez, and they perform under the name Sublime With Rome. This has to be some of the finest reggae to come out of the West Coast – Rome’s voice is amazing, the music has a very timeless feel. I actually listen to it as rarely as I can, for fear of ruining the magic. It’s like Sublime grew up, graduated college, and found its identity – the percussion is bang on, it’s well mixed, has a deep reggae vibe, and Rome’s voice keeps thing very fun, without being stereotypical reggae, as can be common in the states.
Check out Same Old Situation.