19 ms·

The Code Is Just the Symptom

263 points by gvb 12y ago

grandalf 12y ago
It is amazing how culture problems often start with the CEO. Sometimes, non-technical CEOs are very good at their own speciality (selling, motivating, etc.) but extremely bad at systems thinking. Other times, CEOs hire yes-men and yes-women below them and everyone is afraid/unwilling to tell the CEO the truth. Other times the company has raised a ton of money and attracts people who would otherwise not work at a startup and whose major focus is resume building and moving to the next job. If the CEO is the only person meeting with investors or only trusts one or two other people to meet with them that is another big concern. It means there is likely no transparency into the actual team and what is actually going on, which means the CEO is likely BSing the investors. All of these are reasons why you should not work at a startup if you do not 100% believe in the CEO. Be skeptical b/c most startup CEOs really do not have a track record of insight and integrity. If the CEO is aloof or seems out of touch and not someone who you think would really enjoy talking to you about your job and who respects the work you do, be wary.
- grayfox 12y ago
  Terrific insight. My situation at present has taught me many of these lessons... New comers to start-ups, do take heed!
- jacquesm 12y ago
  In five words: fish rots from the head.
- monk_e_boy 12y ago
  Replace CEO with "owner of small business" and this is what I see endlessly. The chops needed to build a business and sell a product are a long way along a spectrum from how to grow that business and how to keep the codebase stable.
  - jnbiche 12y ago
    Agreed. Amazingly, some of them are even "technical", but have no concept of technical debt, and zero respect for software engineering practices that don't lead directly to new features. Either they never understood these things in the first place (since this is usually not taught as part of a degree in CS or EE) or they've long since forgotten them.
    - monk_e_boy 12y ago
      I'm upfront and start the conversation with, "You employed me to give you an honest opinion. I think we are going in the wrong direction, we need more tests and some refactoring. This will cost us money now, but save money later." and I always get the reply that sure, they totally understand, but we're going to do a quick and dirty hack today and sort it all out next week... I used to just refactor and test as I went along, but then you end up ruffling feathers and being slower that others. This is then used as ammo against you. So you lose by doing the right thing. I think pouring energy into other things (open source) is more productive.
    - derefr 12y ago
      You can be "technical" without a need for a concept of technical debt. - Indie video game designer/developers, for example, live in a world where everything they write is a one-off product that will ship, at most, a v1.0.4 six years after v1.0.0. To them, code is a medium for crafting an experience, and whether the code is of quality is immaterial as long as it creates the correct experience. - Data scientists (and bioinformatics pepole, and a few other similar groups) live in a world where everything they write is effectively a script-as-experimental-apparatus. If the script is producing output conforming to the proposed experimental method, then it's done. They run it, then discard it. It's not usually even under version control; only recently have such scripts been considered worth including for purposes of peer review and replication. And there are other examples. I'm not saying that these kind of people are "software engineers"—engineering of any kind is never even a consideration for them; whether the product is well-engineered has no impact on their livelihoods. But these people frequently are lumped into the category of "programmers", and that tends to confuse this sort of discussion a lot. The "software industry" doesn't just contain engineers doing engineering (well or poorly); it also contains prototypers and illusionists and tinkers and scientists, all working to their own criteria of art, none of whom will have any reason to pick up a single shred of engineering knowledge, even with decades spent in their own industries. And then these people apply for "programming jobs", and we wonder why they don't know what git is or how to properly modularize a codebase for maintainability. It's a communication problem, I think. We need to stop calling everything we're doing "programming." Maybe we need an entirely new verb for doing software engineering, of the kind you do when you're writing something like car firmware, or Amazon S3, or the Googlebot. "Programming" is about as precise in describing that as "doing math" is in describing the invention of the lambda calculus.
- coffeemug 12y ago
  > If the CEO is the only person meeting with investors or only trusts one or two other people to meet with them that is another big concern. I know you said 'concern' and not 'problem', but I generally do this and have a totally different motivation for it. Our guys and gals are really busy. There is a lot of work (often very specialized work) that needs to get done, and it's important to shield them from distractions. Investors generally tend to helicopter up -- they see our world/company from thirty thousand feet. It's a totally different perspective that takes some time and experience to get used to. Even most CEOs have trouble shifting into this mindset. It requires an enormous context shift. For people who don't have a lot of experience with this kind of thing, it can be dramatically harder to do it on a whim. A minute ago you were sitting at your computer, trying to figure out a C++ boost error message, and now someone asks you "how do you think the feature you're working on will impact the company's revenue in the next quarter?" That can really throw people off. They might feel like they should have had a better answer. Investor conversations can seem extremely important to people who aren't used to doing it on regular basis, and it can distract them from critical work. I think it's good general practice to try and avoid it. That doesn't mean undue paranoia -- if someone wants to talk to the investor (or the other way around), they're welcome to. But I think being thoughtful about protecting your people that are neck deep in work from distractions is usually a good policy.
  - grandalf 12y ago
    I think at a certain point a company reaches a size where there are functional units that generally do independent work and the founder has little to do with it -- if an investor has an interest in that area (or ideally experience/advice to offer) it makes sense for some members of the team to be involved in the dialog, though probably not the guy writing the algorithms in c++.
TerryADavis 12y ago
I wrote all the code. Opinions are like ass-holes. Everybody's got one. God communicates all the time, keeping the design just like He wants it. He also puppets me and makes the evolution of the code divine intellect in the end.
mosburger 12y ago
This was a very interesting read, but I was a little disappointed that it didn't leave me with a sense of resolution. Did company B get "fixed?" How? How have other companies resolved culture issues that stem from the leadership at the top? Are companies with these kinds of problems just doomed to fail?
- fromtheoutside 12y ago
  Usually companies like this can fail for a very long time. As long as someone is willing to pay, you can live with the slow development speed, the high number of bugs and the constant team changes.
  - monk_e_boy 12y ago
    this exactly. I expect they are paying below average wages, have huge churn of people looking for anything to do while the perfect job arises. Throw in some people new to the area who need a job now, some old contractors who have money and are looking for pocket money and more stability (who's CVs are amazing, they have the gift of the gab but get bored really really quickly and just don't care about the job) and that is a the instant recipe for churn and crap code.
  - scolfax 12y ago
    Agreed
  - nostrademons 12y ago
    ...which indicates that they aren't necessarily wrong in their assessment that those things aren't important. It makes me wish the OP had named the industry & market, though. Companies like these are ideal prey for entrepreneurs.
- savanaly 12y ago
  I agree. This felt like the first 25% of an essay, actually. Would love to read more from this author.
  - 12y ago
vinceguidry 12y ago
Our CEO hired a VP of e-commerce last year, before there was just an over-worked director handing me down directives from on high. As the sole back-end engineer inheriting an ancient codebase, I've been able to keep things reasonable and clean and not build new crap on top of old crap. But it's taken the careful exercise and maintenance of leverage. Now we're gaining traction and pushing back on the on-high directives and coming up with a solid long-term plan. I shudder to think what it would have looked like if there were a whole team of engineers with nobody to add their voice to the leadership. Engineers don't help this problem when they treat management like idiot work.
- protonfish 12y ago
  Engineers don't help the problem when they treat management like glorious god-like perfect beings either. When your management is bad, there is nothing an engineer can do. They can attempt to bring their concerns to leadership, look for another job, or play the fiddle while the product burns to the ground. Speaking of bad management, I was very surprised when he claimed that the situation where you are asked to "...make architectural decisions on the fly without knowing anything about what their problems are" he had never experienced before. In all of my experience, it was standard practice.
  - vinceguidry 12y ago
    > When your management is bad, there is nothing an engineer can do. They can attempt to bring their concerns to leadership, look for another job, or play the fiddle while the product burns to the ground. Well, they could step up and start fixing problems in the organization themselves. Improving communication flow between departments, building better processes, discovering metrics, these are things that you can do to help make your company better without having to get the leadership involved. Not every improvement needs grand strategy, there's often lots of low-hanging fruit that one person can own and push by themselves. Just Friday I was sitting in on a planning meeting and realizing that while we have a front-end guy, we don't really have a decent web designer that can draw out ideas and come up with plans for implementing them. So now I'm thinking about how to go about the task of managing that information flow.
beat 12y ago
There must be a corollary to Conway's Law here... the dysfunction of the code produced by an organization reflects the dysfunction of the communication structures of that organization.
- chadgeidel 12y ago
  I'm pretty sure Conway's Law already covers that condition. It only says that the design mimics the communication structure.
- Confusion 12y ago
  Yeah, I think that's an interedting amendment to Conway's law: it's not just about the structure of the organisation/communication, but also about the feelings associated with the communication.
  - beat 12y ago
    It's kind of a consequence of Conway's Law. I don't know if that's best expressed as a corollary or as something else.
andrewvc 12y ago
It's amazing that we've known for decades that concentrating decision making at the top leads to outcomes like this. It's far better to push decisions as low as possible, and let higher ups coordinate those decisions, and only overrule when absolutely necessary.
- databass 12y ago
  In the case of an architecture diagram being handed down from on high, sure. But in the case of product feature whack-a-mole, this doesn't seem like something that bottom-up decision-making could fix.
  - andrewvc 12y ago
    And that's where the "as possible" part of "as low as possible" comes in. :)
Terr_ 12y ago
When I was younger, immersed in usability, databases, and big sites, watching the initial rollout of Facebook etc, I thought that a good technical solution could solve social ones. Now I'm a lot more pessimistic and want to approach it the other way around.
- ayuvar 12y ago
  One of the common themes at my last gig is that I would start conversations and presentations with "There are no technical problems here. These are people problems." Eventually they tried to solve both problems by adopting a technical solution so bad that the people left.
  - mooreds 12y ago
    Peopleware is a great book about this very concept. http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects... A book from 1987! Nothing new under the sun.
metaphorm 12y ago
I thought this was a good read and I'd be interested in reading a longer piece on the topic. Hopefully the author will continue writing on this theme.
jalopy 12y ago
Love this article, but I'm not sure the origin of the sloppy practices described there always originates with the VP/Eng, CTO or CEO. I've worked with plenty of engineers who just don't want to write tests, or tighten up code, or expend the effort to socialize their ideas/accept others. The higher ups might not have the visibility, inclination (or time!) to focus on those issues and encourage best practices, but I don't always detect acts of commission from them to subvert best practices.
- Consultant32452 12y ago
  If you have developers who refuse to write tests and can't or won't communicate with the other people on the team, then it's definitely a management problem to not get rid of those people. And the culture of not getting rid of people is definitely one that tends to start pretty high up the chain of command.
- badlucklottery 12y ago
  I don't know if he was saying it always originates from the top but more that it's always allowed to perpetuate from there. If management doesn't have the visibility/inclination/time to peer into problems and gain understanding, they are encouraging whatever has happened to continue happening for better or worse.
- s73v3r 12y ago
  At the end of the day, the CEO/CTO/VP of Eng are responsible for them. The buck stops there.
- jalopy 12y ago
  Agree with all the responses to my top level comment, in that management is ultimately responsible for setting and maintaining the engineering culture. It can be tough, however, to balance competing (tensioned) requirements - if you have to choose between engineers that follow best practices (user stories, standups, TDD, pairing, etc) and no engineers at all (let's face it, they are scarce today) - what do you do? Wait to hire engineers and let the product deadline slip even further? It's a tough balancing act.
calinet6 12y ago
Really great article. This is what Deming (old school father of the concept of quality control) was getting at with his view of organizations. http://en.wikipedia.org/wiki/W._Edwards_Deming http://en.wikipedia.org/wiki/W._Edwards_Deming This topic is traditionally covered under the umbrella of Quality, with the premise that output Quality is primarily a function of the systems, knowledge, and understanding of the people at an organizational level—and is not a primarily technical pursuit, despite what most people think. We need this discussion in the software world now more than ever. Really glad to see it.
bkeroack 12y ago
This is what happens when engineers subordinate themselves to non-technical management in a business-driven (as opposed to engineering-driven) organization. The ironic/tragic thing is that the consultants who are brought in at much expense (and who therefore have some credibility with "the business") are often no better than--usually worse than--the in-house engineers they are supposed to help. If you ever find yourself an engineer in a dynamic like this, you should interpret it as a sign of mistrust--even outright disrespect--of you and your peers by your bosses. Imagine if you were a physician and hospital management thought it necessary to bring in outside physicians to help you with your patients. Not many doctors I know would put up with that, but engineers are culturally so submissive that they go along with it and deal with the Dilbert scenario of the $500/hour consultant giving the same recommendations the in-house engineers have been saying all along (which the consultants get credit for, of course). If you're ever in a position of authority and feel that it's necessary to bring in consultants to "fix" your codebase, it would be worthwhile to reflect for a few moments on how this situation came to be. Either you failed your organization on the hiring front and have terrible engineers (unlikely), or your otherwise talented engineers cannot do their jobs effectively due to the environment you've created. Perhaps you've forced them to incur so much technical debt by nonstop "sprints", unrealistic deadlines and multiple pivots that any forward progress is all but impossible. Consultants probably won't fix this.
- tieTYT 12y ago
  > Either you failed your organization on the hiring front and have terrible engineers (unlikely) What makes you say that is unlikely?
  - bkeroack 12y ago
    If you accept that engineering skill fits the normal distribution, it's less likely that they are "terrible" than merely average. Amazing 10X engineers could still pull off shipping a working product even with all the organizational handicaps I mentioned in my earlier post. This doesn't excuse the deficiencies of the organization, nor does it mean that "average" engineers are undesirable or can't do good work. I agree with the theme of the cited article--rather than scapegoat the engineers and pay external consultants to "fix their mistakes", fix the organization and enable the engineers to do quality work.
M8 12y ago
Ruby in a large app and also untested. A recipe for disaster.
- jalopy 12y ago
  Not sure how Ruby the language is unique here. Doesn't the rest of the statement apply when you substitute any other language?

263 points by gvb 12y ago

It is amazing how culture problems often start with the CEO. Sometimes, non-technical CEOs are very good at their own speciality (selling, motivating, etc.) but extremely bad at systems thinking. Other times, CEOs hire yes-men and yes-women below them and everyone is afraid/unwilling to tell the CEO the truth. Other times the company has raised a ton of money and attracts people who would otherwise not work at a startup and whose major focus is resume building and moving to the next job. If the CEO is the only person meeting with investors or only trusts one or two other people to meet with them that is another big concern. It means there is likely no transparency into the actual team and what is actually going on, which means the CEO is likely BSing the investors. All of these are reasons why you should not work at a startup if you do not 100% believe in the CEO. Be skeptical b/c most startup CEOs really do not have a track record of insight and integrity. If the CEO is aloof or seems out of touch and not someone who you think would really enjoy talking to you about your job and who respects the work you do, be wary.

grayfox 12y ago
Terrific insight. My situation at present has taught me many of these lessons... New comers to start-ups, do take heed!
jacquesm 12y ago
In five words: fish rots from the head.
monk_e_boy 12y ago
Replace CEO with "owner of small business" and this is what I see endlessly. The chops needed to build a business and sell a product are a long way along a spectrum from how to grow that business and how to keep the codebase stable.
- jnbiche 12y ago
  Agreed. Amazingly, some of them are even "technical", but have no concept of technical debt, and zero respect for software engineering practices that don't lead directly to new features. Either they never understood these things in the first place (since this is usually not taught as part of a degree in CS or EE) or they've long since forgotten them.
  - monk_e_boy 12y ago
    I'm upfront and start the conversation with, "You employed me to give you an honest opinion. I think we are going in the wrong direction, we need more tests and some refactoring. This will cost us money now, but save money later." and I always get the reply that sure, they totally understand, but we're going to do a quick and dirty hack today and sort it all out next week... I used to just refactor and test as I went along, but then you end up ruffling feathers and being slower that others. This is then used as ammo against you. So you lose by doing the right thing. I think pouring energy into other things (open source) is more productive.
  - derefr 12y ago
    You can be "technical" without a need for a concept of technical debt. - Indie video game designer/developers, for example, live in a world where everything they write is a one-off product that will ship, at most, a v1.0.4 six years after v1.0.0. To them, code is a medium for crafting an experience, and whether the code is of quality is immaterial as long as it creates the correct experience. - Data scientists (and bioinformatics pepole, and a few other similar groups) live in a world where everything they write is effectively a script-as-experimental-apparatus. If the script is producing output conforming to the proposed experimental method, then it's done. They run it, then discard it. It's not usually even under version control; only recently have such scripts been considered worth including for purposes of peer review and replication. And there are other examples. I'm not saying that these kind of people are "software engineers"—engineering of any kind is never even a consideration for them; whether the product is well-engineered has no impact on their livelihoods. But these people frequently are lumped into the category of "programmers", and that tends to confuse this sort of discussion a lot. The "software industry" doesn't just contain engineers doing engineering (well or poorly); it also contains prototypers and illusionists and tinkers and scientists, all working to their own criteria of art, none of whom will have any reason to pick up a single shred of engineering knowledge, even with decades spent in their own industries. And then these people apply for "programming jobs", and we wonder why they don't know what git is or how to properly modularize a codebase for maintainability. It's a communication problem, I think. We need to stop calling everything we're doing "programming." Maybe we need an entirely new verb for doing software engineering, of the kind you do when you're writing something like car firmware, or Amazon S3, or the Googlebot. "Programming" is about as precise in describing that as "doing math" is in describing the invention of the lambda calculus.
coffeemug 12y ago
> If the CEO is the only person meeting with investors or only trusts one or two other people to meet with them that is another big concern. I know you said 'concern' and not 'problem', but I generally do this and have a totally different motivation for it. Our guys and gals are really busy. There is a lot of work (often very specialized work) that needs to get done, and it's important to shield them from distractions. Investors generally tend to helicopter up -- they see our world/company from thirty thousand feet. It's a totally different perspective that takes some time and experience to get used to. Even most CEOs have trouble shifting into this mindset. It requires an enormous context shift. For people who don't have a lot of experience with this kind of thing, it can be dramatically harder to do it on a whim. A minute ago you were sitting at your computer, trying to figure out a C++ boost error message, and now someone asks you "how do you think the feature you're working on will impact the company's revenue in the next quarter?" That can really throw people off. They might feel like they should have had a better answer. Investor conversations can seem extremely important to people who aren't used to doing it on regular basis, and it can distract them from critical work. I think it's good general practice to try and avoid it. That doesn't mean undue paranoia -- if someone wants to talk to the investor (or the other way around), they're welcome to. But I think being thoughtful about protecting your people that are neck deep in work from distractions is usually a good policy.
- grandalf 12y ago
  I think at a certain point a company reaches a size where there are functional units that generally do independent work and the founder has little to do with it -- if an investor has an interest in that area (or ideally experience/advice to offer) it makes sense for some members of the team to be involved in the dialog, though probably not the guy writing the algorithms in c++.

TerryADavis 12y ago

I wrote all the code. Opinions are like ass-holes. Everybody's got one. God communicates all the time, keeping the design just like He wants it. He also puppets me and makes the evolution of the code divine intellect in the end.

mosburger 12y ago

This was a very interesting read, but I was a little disappointed that it didn't leave me with a sense of resolution. Did company B get "fixed?" How? How have other companies resolved culture issues that stem from the leadership at the top? Are companies with these kinds of problems just doomed to fail?

fromtheoutside 12y ago
Usually companies like this can fail for a very long time. As long as someone is willing to pay, you can live with the slow development speed, the high number of bugs and the constant team changes.
- monk_e_boy 12y ago
  this exactly. I expect they are paying below average wages, have huge churn of people looking for anything to do while the perfect job arises. Throw in some people new to the area who need a job now, some old contractors who have money and are looking for pocket money and more stability (who's CVs are amazing, they have the gift of the gab but get bored really really quickly and just don't care about the job) and that is a the instant recipe for churn and crap code.
- scolfax 12y ago
  Agreed
- nostrademons 12y ago
  ...which indicates that they aren't necessarily wrong in their assessment that those things aren't important. It makes me wish the OP had named the industry & market, though. Companies like these are ideal prey for entrepreneurs.
savanaly 12y ago
I agree. This felt like the first 25% of an essay, actually. Would love to read more from this author.
- 12y ago

vinceguidry 12y ago

Our CEO hired a VP of e-commerce last year, before there was just an over-worked director handing me down directives from on high. As the sole back-end engineer inheriting an ancient codebase, I've been able to keep things reasonable and clean and not build new crap on top of old crap. But it's taken the careful exercise and maintenance of leverage. Now we're gaining traction and pushing back on the on-high directives and coming up with a solid long-term plan. I shudder to think what it would have looked like if there were a whole team of engineers with nobody to add their voice to the leadership. Engineers don't help this problem when they treat management like idiot work.

protonfish 12y ago
Engineers don't help the problem when they treat management like glorious god-like perfect beings either. When your management is bad, there is nothing an engineer can do. They can attempt to bring their concerns to leadership, look for another job, or play the fiddle while the product burns to the ground. Speaking of bad management, I was very surprised when he claimed that the situation where you are asked to "...make architectural decisions on the fly without knowing anything about what their problems are" he had never experienced before. In all of my experience, it was standard practice.
- vinceguidry 12y ago
  > When your management is bad, there is nothing an engineer can do. They can attempt to bring their concerns to leadership, look for another job, or play the fiddle while the product burns to the ground. Well, they could step up and start fixing problems in the organization themselves. Improving communication flow between departments, building better processes, discovering metrics, these are things that you can do to help make your company better without having to get the leadership involved. Not every improvement needs grand strategy, there's often lots of low-hanging fruit that one person can own and push by themselves. Just Friday I was sitting in on a planning meeting and realizing that while we have a front-end guy, we don't really have a decent web designer that can draw out ideas and come up with plans for implementing them. So now I'm thinking about how to go about the task of managing that information flow.

beat 12y ago

There must be a corollary to Conway's Law here... the dysfunction of the code produced by an organization reflects the dysfunction of the communication structures of that organization.

chadgeidel 12y ago
I'm pretty sure Conway's Law already covers that condition. It only says that the design mimics the communication structure.
Confusion 12y ago
Yeah, I think that's an interedting amendment to Conway's law: it's not just about the structure of the organisation/communication, but also about the feelings associated with the communication.
- beat 12y ago
  It's kind of a consequence of Conway's Law. I don't know if that's best expressed as a corollary or as something else.

andrewvc 12y ago

It's amazing that we've known for decades that concentrating decision making at the top leads to outcomes like this. It's far better to push decisions as low as possible, and let higher ups coordinate those decisions, and only overrule when absolutely necessary.

databass 12y ago
In the case of an architecture diagram being handed down from on high, sure. But in the case of product feature whack-a-mole, this doesn't seem like something that bottom-up decision-making could fix.
- andrewvc 12y ago
  And that's where the "as possible" part of "as low as possible" comes in. :)

Terr_ 12y ago

When I was younger, immersed in usability, databases, and big sites, watching the initial rollout of Facebook etc, I thought that a good technical solution could solve social ones. Now I'm a lot more pessimistic and want to approach it the other way around.

ayuvar 12y ago
One of the common themes at my last gig is that I would start conversations and presentations with "There are no technical problems here. These are people problems." Eventually they tried to solve both problems by adopting a technical solution so bad that the people left.
- mooreds 12y ago
  Peopleware is a great book about this very concept. http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams http://en.wikipedia.org/wiki/Peopleware:_Productive_Projects... A book from 1987! Nothing new under the sun.

metaphorm 12y ago

I thought this was a good read and I'd be interested in reading a longer piece on the topic. Hopefully the author will continue writing on this theme.

jalopy 12y ago

Love this article, but I'm not sure the origin of the sloppy practices described there always originates with the VP/Eng, CTO or CEO. I've worked with plenty of engineers who just don't want to write tests, or tighten up code, or expend the effort to socialize their ideas/accept others. The higher ups might not have the visibility, inclination (or time!) to focus on those issues and encourage best practices, but I don't always detect acts of commission from them to subvert best practices.

Consultant32452 12y ago
If you have developers who refuse to write tests and can't or won't communicate with the other people on the team, then it's definitely a management problem to not get rid of those people. And the culture of not getting rid of people is definitely one that tends to start pretty high up the chain of command.
badlucklottery 12y ago
I don't know if he was saying it always originates from the top but more that it's always allowed to perpetuate from there. If management doesn't have the visibility/inclination/time to peer into problems and gain understanding, they are encouraging whatever has happened to continue happening for better or worse.
s73v3r 12y ago
At the end of the day, the CEO/CTO/VP of Eng are responsible for them. The buck stops there.
jalopy 12y ago
Agree with all the responses to my top level comment, in that management is ultimately responsible for setting and maintaining the engineering culture. It can be tough, however, to balance competing (tensioned) requirements - if you have to choose between engineers that follow best practices (user stories, standups, TDD, pairing, etc) and no engineers at all (let's face it, they are scarce today) - what do you do? Wait to hire engineers and let the product deadline slip even further? It's a tough balancing act.

calinet6 12y ago

Really great article. This is what Deming (old school father of the concept of quality control) was getting at with his view of organizations. http://en.wikipedia.org/wiki/W._Edwards_Deming http://en.wikipedia.org/wiki/W._Edwards_Deming This topic is traditionally covered under the umbrella of Quality, with the premise that output Quality is primarily a function of the systems, knowledge, and understanding of the people at an organizational level—and is not a primarily technical pursuit, despite what most people think. We need this discussion in the software world now more than ever. Really glad to see it.

bkeroack 12y ago

This is what happens when engineers subordinate themselves to non-technical management in a business-driven (as opposed to engineering-driven) organization. The ironic/tragic thing is that the consultants who are brought in at much expense (and who therefore have some credibility with "the business") are often no better than--usually worse than--the in-house engineers they are supposed to help. If you ever find yourself an engineer in a dynamic like this, you should interpret it as a sign of mistrust--even outright disrespect--of you and your peers by your bosses. Imagine if you were a physician and hospital management thought it necessary to bring in outside physicians to help you with your patients. Not many doctors I know would put up with that, but engineers are culturally so submissive that they go along with it and deal with the Dilbert scenario of the $500/hour consultant giving the same recommendations the in-house engineers have been saying all along (which the consultants get credit for, of course). If you're ever in a position of authority and feel that it's necessary to bring in consultants to "fix" your codebase, it would be worthwhile to reflect for a few moments on how this situation came to be. Either you failed your organization on the hiring front and have terrible engineers (unlikely), or your otherwise talented engineers cannot do their jobs effectively due to the environment you've created. Perhaps you've forced them to incur so much technical debt by nonstop "sprints", unrealistic deadlines and multiple pivots that any forward progress is all but impossible. Consultants probably won't fix this.

tieTYT 12y ago
> Either you failed your organization on the hiring front and have terrible engineers (unlikely) What makes you say that is unlikely?
- bkeroack 12y ago
  If you accept that engineering skill fits the normal distribution, it's less likely that they are "terrible" than merely average. Amazing 10X engineers could still pull off shipping a working product even with all the organizational handicaps I mentioned in my earlier post. This doesn't excuse the deficiencies of the organization, nor does it mean that "average" engineers are undesirable or can't do good work. I agree with the theme of the cited article--rather than scapegoat the engineers and pay external consultants to "fix their mistakes", fix the organization and enable the engineers to do quality work.

M8 12y ago

Ruby in a large app and also untested. A recipe for disaster.

jalopy 12y ago
Not sure how Ruby the language is unique here. Doesn't the rest of the statement apply when you substitute any other language?