15 ms·

The Quiet Crisis Unfolding in Software Development

• eistrati 10y ago
  This resonates with my experience. I agree that it requires a weird name to start productive conversations :)
• snarfy 10y ago
  I think the crisis is bigger than software development. It's evident at all levels of society. There is a real lack of leadership in the world. Everybody is so averse to risk and afraid to follow their own beliefs that they end up doing what everybody else is doing. That is not what leaders do. This is how we end up with scrum. It's also how we end up with partisan politics, a dozen sequels of the same movie, and nickelback.
• sbmassey 10y ago
  This is a good analysis, but it needs a silly name to be accepted as a new management trend.
  • ClassyHacker 10y ago
    Software Development Management for Dummies
    • davidjnelson 10y ago
      I like that :-) To rearrange the letters slightly for a better acronym; "Managing Software Development for Dummies", or MSDD ;-)
• scott_wilson46 10y ago
  This all seems highly sensible advice to me!
• tetraodonpuffer 10y ago
  excellent article, it is especially interesting the advice on being liberal with promotions and technical career track, given that in several companies I've worked for when you get to a certain level (principal/staff/lead/... whatever) getting promoted further is an exercise in frustration, because either there are only X slots (we can't have more than X fellow positions in the company) or it becomes a matter of having to play politics, or you end up in companies where the technical ladder has a (sometimes low) glass ceiling. I would've added a paragraph on stack ranking and curve ranking in general, which although obviously extremely detrimental to morale and retention, still unfortunately rears its head at times, and one about how to handle layoffs/restructurings as those are not easy to do well.
• skybrian 10y ago
  Sensible advice, but I didn't see anything about a quiet crisis.
  • michaelwww 10y ago
    I took from it that the quiet crisis is an increase over the last 10 to 15 years of the opposite of what he recommends: rewarding high performers without making sure they are not taking shortcuts, not allowing people time to clean up technical debt, treating developers as interchangeable so they don't feel code ownership, not recognizing natural leaders with promotions and raises, using misleading metrics that encourage gaming the system, allowing developers to be unnecessarily interrupted during their workday, open floor plans that produce a distracting environment, not allowing time for exploratory side projects, limiting mobility within a company so a developer unhappy in a group can't move to another, turning down small requests like a new keyboard, waiting too long to do a employee review, treating management as a step up from software developer (as being better than,) placing too much emphasis on having young energetic employees and not appreciating the experience and wisdom that older employees bring to the group, arbitrary corporate rules like overly conservative dress codes.
    • crdoconnor 10y ago
      This is a problem that affects more than just programmers. Management is seen more these days as a generic function performed by a special (upper) class of people and less as a function performed by high performers in their respective fields. This happened in medical care (the rise of non-medical medical management), academia (c.f. the rise of administrative positions in university), charter schools and industry, too. The problems he complains about are consequences of this more general shift - when managers do not understand what it is they manage, they seek out brain dead metrics to measure performance, which, in the absence of understanding the field, severely damages performance. Programmers have more in common with welders, doctors, nurses, lawyers, teachers, etc. than they seem to think.
  • emeraldd 10y ago
    The crisis is that software shops are ignoring the basics and pushing "fadish" solutions: "... I’ve noticed a quiet crisis unfolding in software development leading to low quality applications, unhappy employees and unhappy users. Silver bullet solutions keep creeping into our awareness (Scrum, anyone?) and predictably keep letting us down. This is almost entirely the fault poor management — or perhaps it should be called fad management."
• emeraldd 10y ago
  "If design and code reviews aren’t highly interactive with lots of questions and recommendations, your employees aren’t taking them seriously or they’re too shy to speak up. Very often one or two developers are interested in them but without obvious interest and input from the rest of the team even interested developers will tend to severely curtail their questions and recommendations." This drives me nuts, it manifests itself in some many different ways: * The "immediate" thumbs up on a PR * The PR that sits and languishes forever * The chat room of silence when someone asks an architectural/design question It can get really frustrating. Still no clue of a good way to fix it since the problem stems from a long built team culture that needs to change.
  • philsnow 10y ago
    IANAM so grain of salt. > The "immediate" thumbs up on a PR This one bugs me too. Really? On a PR with 400 delta lines, you didn't need clarification on anything? I don't know what action to take here. > The PR that sits and languishes forever Get your team to agree to an PR review SLA on the order of a day or two. "Enforce" the SLA -- how you do this depends on your team and the situation, but it can help to just remind people that they collectively agreed to the SLA. Suggest reviewing PRs with the same cadence as checking email (~1-2x per day). > The chat room of silence when someone asks an architectural/design question Identify one or more "natural leaders" as mentioned in the article, and encourage them to check on the chat room periodically (email cadence?) to route questions to the most likely person. They should know who that person is because they're generally well-connected, and mentioning them by name creates social pressure for that person to respond.
    • ChemicalWarfare 10y ago
      On the flip side - to properly review a 400 line pr would take hours unless you were involved in discussions with the developer along the way like let's say he's making changes to the api while you're working on the consuming client. I typically ask for the devs to push their code into the repo incrementally as long as the change doesn't break anything. That way you have manageable prs and if there's a need to go back to the previous version you have smaller deltas to deal with as well.
• NKCSS 10y ago
  The best piece I've read on the subject; I agree with everything he has written and it's the stuff I've told management at many companies I've been at. I've yet to see any of them listen to me though; usually, if they don't do things the way outlined here, they just don't get it and the offered reasons will not resonate.
  • geoka9 10y ago
    I agree, I could have written the same essay myself! Except for the last point: > but a nice pair of jeans and any decent shirt with a collar should do just fine. Why should there be such a requirement? Why can't people wear shorts and/or t-shirts if they want? Of course there should be some requirement (like having some kind of clothes on) but otherwise I don't think any code is necessary as long as the team is comfortable.
    • NKCSS 10y ago
      I understanding where you are coming from; I thought the same when I was a few years younger and was wearing t-shirts with texts like "not even Norton can protect you", "every time you download music, God kills a kitten" and "I read your e-mail". And while those are a lot of fun, it's not fun to explain to customers and have to say: "Don't mind them, they are just our developers..."
      • douche 10y ago
        Question: Why are your customers seeing your developers?
        • NKCSS 10y ago
          Multiple scenarios that I've encountered. 1) company that creates custom modules for firms coal software; it always involves meeting the customer. 2) Open office layouts where customers are given a tour of the Office.
          • 10y ago
• dclowd9901 10y ago
  > These leaders should also be publicly recognized as such. Promote them to the job they’re already doing. This formalization makes it easier for them to assist other developers without hard feelings — it’s now part of their official job description! — and provides them with recognition which increases morale. Without that official recognition, providing assistance can often feel like little more than an unwelcome burden. Don’t let that happen to your employees. Piggy-backing off of this astute suggestion, I'd also like to say that it signals to other developers in the org that the org appreciates and rewards people stepping up. This can be hugely important for retaining talent -- it's the difference between whether an employee thinks they have somewhere to go in their current org, or if they have to leave to step up.
• rcarmo 10y ago
  The open space bit keep nagging at me. I've liked and hated it in equal parts, but the truth is that as soon as I was able to spend time working from home I stopped wanting to go to the office daily, period. I'm so much more productive when not sharing a table with a half dozen folk.
  • louprado 10y ago
    Same here. IME it also makes you like your team more. I once sat next to a software developer who always listened to talk shows/lectures while developing. I then resented having to maintain or add features to code he touched. When I started working from home, I can just tell myself that he's focused and trying his best (which may have always been the case). It still looks like code developed by someone who is distracted but I no longer know that for a fact.
  • douche 10y ago
    After working primarily remote (in the office one day a week) for six months, it's been extremely hard to get back in the grind of having to go to the office again. I have a mostly private corner office, so it's not some open-office Lord of the Flies situation, but still, I'm so much more productive in a space that I control fully, where there are no casual distractions, and I don't have my blood-pressure and pissiness levels cranked up by having to commute in and deal with traffic in the morning. If anything, I communicate more when I'm at home than when I'm in the office... Excessively verbal people don't seem to be able to handle it well, however, from what I've seen.
  • bayonetz 10y ago
    Open floor plans are ~80% of the time about cutting cost but only about ~20% of the time is this actually admitted by executives. There are plenty of problems at my current job but being cattle caged in an open floor plan is not one of them. Almost 100% of the time my introverted self performs an order of magnitude better within the sweet sweet sanctuary of my door-locking, fully-enclosed, window-with-some-mountains-in-the-background office. To the point of feeling golden handcuffed by it. I'm sure I'm not a minority in this. I wonder why more companies don't pay the extra, yet in many cases workable, expense.
• ricardobeat 10y ago
  > Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. This does not match my experience in ~10 years as a web developer. I see most of the technical debt coming from low performers, who take longer to deliver a poorer product. Most high-performers perform well precisely because they have mastered certain development processes, tools and good coding practices, which results in higher quality code. I'm thinking this must vary a lot according to your industry.
  • mannykannot 10y ago
    Agreed, and it is not limited to web development. Effective developers seem to know what they are trying to do, have a plan for how to get there, and have a mental map of where they are, while poor developers are groping for a solution in a fog of confusion. The author's claim is almost self-contradictory: if technical debt is bad, then anyone using it to create the illusion of being a high performer will end up hamstrung by his accumulated debt.
    • CaptSpify 10y ago
      IME: The "effective" developer is never the one who has to clean up the accumulated debt though. They are pushed off to new projects before the warts start to show. It's everyone else that has to clean up after them.
      • khedoros 10y ago
        Yep. They're moved on to the next project that needs their speed and expertise. Cleaning up the mess is usually left to those who don't pump out new lines of code quite as fast.
      • mannykannot 10y ago
        Good point - I have seen that myself.
  • 10y ago
• Bahamut 10y ago
  I like this article on a whole, but I do have a comment on this quote > Optimizing for the common scenario means giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working. I have worked with someone overly protective of the code sector he wrote, but it has caused problems since I would like to fix some bugs in the API signature of that code, but the developer has stonewalled me in the past & raised a ruckus when I filed PRs to fix some of it. If it is something that affects how other people interface with a feature, IMO it is not a good thing to necessarily designate a primary owner & mandate all changes go through him/her. Granted, some of the problem is that the other developer probably was in the wrong being obstinate, but you work with the cards you're given.
  • cpeterso 10y ago
    Mozilla addresses this, in part, by having one "module owner" but also multiple "module peers". All code changes in a module should be reviewed by the owner or (more usually) a peer. Having multiple peers reduces module owners' review burden, reduces bus factor, and gives "reviewees" someone they can appeal to if their PR is rejected. Linux has a similar organization with Linus' "lieutenants".
  • mmatants 10y ago
    It makes sense to have centrality of vision for how code should be laid out. This is software architecture (as skill and role, not title though!). And as people have a limited focus span, it makes sense to segment - by business topic, by API, etc. But of course fiefdoms emerge. In some ways, it might then almost be better to not have that person contribute to same codebase: to avoid ego pissing contests and to keep the opposing pressures in balance. The pressures being: delivering features on time on one hand, and keeping things clean and orderly on the other hand. Often, if the architect codes then they can't see their own mistakes, but have 20/20 vision of others' grubby flaws, and hence gain subconscious animosity towards external contributions. That being said, an architect who does not code is even worse! This is where we get ivory tower Architect-as-title, and even less gets done. I wonder what the optimal middle ground is.
• vigilant 10y ago
  There seems to be a lack of emphasis on 'shipping working software' in this list. As a developer, that is what I ultimately want to be judged on. Nothing else. And too many managers judge developers by how closely they adhere to their silver bullet development process which they read in a random website. It seems like the only ways to do this are 1) Create a startup, ship something awesome, have a great exit 2) Work for wall street, in a position where your success is judged by how much money you make, which directly drives your bonus.
  • cpeterso 10y ago
    Good management needs to tend to the longer term health of their team and organization. A rockstar developer shipping working software is good, but when that person quits or no one understands their code or they're a jerk causing other team members to be unhappy, that is a problem.
  • crdoconnor 10y ago
    >There seems to be a lack of emphasis on 'shipping working software' in this list. As a developer, that is what I ultimately want to be judged on. I'm not sure I do. Shipping software in a mess of technical debt is much slower than greenfield development or development on a well architected product. I'd ultimately want to be judged by an architect who reads all pull requests and understands at a deep level how all of the code fits together.
  • iofj 10y ago
    What's also missing is how to actually make extensible designs. I have seen very, very few designs that were able to accommodate unforeseen changes, and none that resulted from good coding practices. Most often I've observed that the more process and organization surrounds a development effort, the more likely that effort will outright fail (sometimes by never getting completed, more often by never actually fulfilling the function that was designed for, then abandoned. The difference is that the second kind is very much declared complete). Recently a thorough focus on code hygiene (unit tests taken to a ridiculous levels, for instance) is one more warning sign that it's time to find something else to do. The biggest warning signs are project teams way bigger than they need to be, but ... Code hygiene nazis merely join the documentation madness of a few years back, PMs should control everything because Steve Jobs was a successful asshole, we need 5 design docs before even knowing what the problem is, ...
• eofear 10y ago
  I was agreeing with all his points until he decided to ban ripped jeans !!
• twa927 10y ago
  There are some fine insights but generally it's the old view of managers vs programmers as passive workers. For example, the advice for managers to encourage programmers to do refactoring as part of normal (business-oriented) tasks is skewed. It's programmers who know the field and they should have some power to give refactoring tasks the same value as business-oriented ones. They should be partners. My view is also probably skewed compared to what a typical "software development" company does, but I don't believe that Google or YC startups do this kind of management.
• zepto 10y ago
  "Don’t have Stupid Dress Codes" is then followed by a dress code: "For some of them that’s jeans and a basic collared shirt and for others it’s business casual." Which for the author's arbitrary reasons leaves out jeans and a t-shirt - although this guy makes some good points, this one is a bust.
  • deckard1 10y ago
    yeah, that comment really seemed to show how out-of-touch the author really is. I haven't worked in a place that required a collared shirt in more than a decade. The last few interviews I've had, the interviewer wore a t-shirt and jeans.
    • jake_morrison 10y ago
      He works in a consulting company in Texas. You need to project a certain level of professionalism to make your customers feel comfortable. Sometimes looking weird can be positive, e.g. for designers, but it can be a distraction.
  • raarts 10y ago
    He said stupid dress code and then comes up with a reasonable one.
    • zepto 10y ago
      I don't see how it's reasonable. If you're going to demand a collared shirt, you may as well demand a suit.
• 20years 10y ago
  Lots of good points here. Limit Interruptions and Prefer Private Workspaces are big ones imo. If only companies realized that those 2 things can increase production and output 10 fold. Sure open offices are cheaper but you are paying for it in other ways.
• somethingsimple 10y ago
  I'd add one thing to that list: be wary of genius developers. I currently work on a project where one of the most senior guys was an incredibly smart person. He wrote extremely complex parts of the code that "just work". The trouble is he's now gone from the team, and no one understands why certain things are written the way they are, and people are afraid to touch them. Despite being really smart, this person was not very good at communicating. Your typical shy and introverted little genius who does it all on his own. When asked to explain things, he would just say "trust me, it has to be this way", but wouldn't really explain why he made certain decisions or wrote the code in certain ways. So now we're in a situation where there are parts of the code we can't touch because "he said it had to be this way". Great. I call it personality-oriented engineering. A total failure. This person got to a higher position because management only looked at how smart he was and how he was able to deliver complex solutions that would impress everyone. They failed to realize how bad he was at leaving a legacy of maintainable code that can be moved forward.
  • Smudge 10y ago
    Seconded. The most important thing for me, when writing code, is whether or not I (or someone else) will be able to read it in 6 months. The second most important thing is whether I'll be able to throw this away and replace it with something else, which perhaps counterintuitively means I need to spend more time ensuring the code I'm writing doesn't wrap tendrils of interdependencies into the rest of the codebase. An important part of that is ensuring that any major interfaces/APIs (both internal and external) are simple, predictable, and well-documented. Even following those two rules alone, you can avoid building these complex, black-box solutions that nobody is willing to touch.
  • cpeterso 10y ago
    I think code review can help here. Even genius developers' code should be reviewed and understood by other developers. This can help reduce the bus factor and level up other team members. The genius developer will learn to "dumb down" (hopefully in a good way) their code to reduce overhead to their productivity from long code reviews with many questions.
  • monk_e_boy 10y ago
• Myrmornis 10y ago
  > Despite there not being a single shred of scientific evidence in favor of open office workspaces being a good idea and overwhelming evidence in favor of them being counterproductive for most software developers, this unfortunate fad is currently widespread. Software developers need private workspaces to ply their trade. Yep. Perhaps this could be softened a bit to say there are different sorts of devs, some seem to work OK in open plan offices and some need private work space. But personally I'm in the latter group. My company moved to open office space and I've come to not even think of the office as a place where I get real work done. Thankfully they allow me to work from home as well, that's one of the main things I'll be looking for in future employers. I have to admit I can produce a feeling of moderately intense anger by just thinking of the Yahoo executive banning work from home because she believed that everyone's job involved frequent impromptu hallway chats or whatever the fuck.
• deleted 10y ago
  [deleted]
• BlaneG 10y ago
  Great article. I thought the title was pretty misleading though. My suggestion: Advice for managing succesful teams.
• bettyx1138 10y ago
  this is the best work-related article/essay i've ever read since i started in this field in the 90s. (except for the collared shirt part lol that's odd.)
• mempko 10y ago
  The real crisis is that people are NOT willing to create new software. And I don't mean the "bag of libraries" that much of software seems to be.
• adamconroy 10y ago
  Quietly unfolding? This has been going on for decades. In fact I think it's prevalence is less these days. Not that I think the avg quality is constantly improving.
  • partycoder 10y ago
    I think right now it got out of hand. With a lowered entry barrier to development, now a regular code base feels like reading http://thedailywtf.com/ http://thedailywtf.com/ There's now a social network for developer rants: https://www.devrant.io https://www.devrant.io
    • adamconroy 10y ago
      I guess its a subjective thing, depending on where you have worked and with whom. I'm pretty picky where I work these days, so maybe I haven't witnessed what you are talking about. However I think these days, at the higher end of the spectrum, the general awareness of good programming practices is better than it was 25 years ago. Back then, unit testing frameworks weren't a thing, I didn't see any CI, often code repositories were zips on a file share..., patterns were barely a thing....
• partycoder 10y ago
  If you pick your utility functions poorly, people start adapting to them with unintended consequences: - Burndown charts: Burn lots of tasks fast, even if you are creating more work in the process. - IBM once rated employees based on added lines of code. The result? An explosion of code. Even code that wasn't strictly necessary. - Stack ranking: punish the lowest 20%, reward the top 20%. Sounds reasonable at first, but what happens when employees adapt to it? People stop hiring strong candidates. So over time, when people leave, their replacements get worse over time creating a downwards spiral of worsening talent.
• dpeterson 10y ago
  "Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally" This is repeated over and over in almost every management book; managers are starting to believe it. In the book "The Phoenix Project", Brett, the most technical guy, was the high performer to fix almost everything. The moral in that story was that Brett was also the Fire Starter. No, management need to feel high performers below them actually belong there. Unfortunately technical skills fade and once good managers become bad and incompetent. Worse, most technical managers were never technical. Just this week I had to put out a fire most certainly not caused by me or my code. I inherited a mess from outsourced workers. Any requests to improve the code base were met with disapproval. Some of our custom code interfaces with an external system that has an API. When we upgraded to the latest version of the external system; it became more strict on what it allowed. To help with the migration, management paid many thousands to have three "experts" on the system come in and help make transition to the new version go smoothly. I was not on the migration project. However, when sh@t hit the fan I was called in. Testing was poor and they went live. The three experts could not find the cause of major problems and certainly no one else on the team was willing to step up. I had to spend the entire week becoming an expert on the external system and quickly fix the problem. Yes, I am a high performer and I did not cause the fire. It is because I roll up my sleeves, get to work and never give up. I'm sorry if that scares some management. That they actually need some people.
• maxxxxx 10y ago
  "at a minimum each developer should have a cubicle with high cube walls and a small entrance" Sounds more like a prison cell. How about daylight or a window?
• swehner 10y ago
  It's almost as if the crisis is all these people that think this or that little item, feature, observation, insight, idea, etc. is soooo terribly important.