Just as in manufacturing, you cannot produce quality by blaming the individual worker. Japanese manufacturers learned this from W. Edwards Deming (http://en.wikipedia.org/wiki/W._Edwards_Deming) and it continues to be true to this day, but for some reason the natural human instinct is to blame the individuals instead of the systems.
Improve your individuals and you can improve your quality maybe twofold, threefold at best. You might chance upon a "rockstar," but probably not.
Worse, blame your individuals and you lose productivity, lose trust, lose culture, instill fear, and break ties. Negative reinforcement brings unpredictable negative consequences.
Improve your systems, your culture, your process, your communication, and everything surrounding the production of your product, and you can improve your quality tenfold or more, and more importantly, be better prepared for a 100x or 1000x growth.
Blame your systems and they can only get better.
I can't think of a time when it's incorrect to think from a systems-first perspective.
We're feeling a lot of pressure at my workplace, especially for a team of new hires that only formed less than 90 days ago. We've barely had a chance to get a handle on this legacy codebase or form habits, never mind start cranking out new features right away.
I don't expect a factory to produce maximum widgets halfway through its own construction process.
I'm a huge fan of Deming, and many of the problems we see in software can be fixed by paying closer attention to his 14 principles.
One question that I've had applying him to software, though, is how you align his concepts on systemic defects (most defects are common causes) with the high variety of performance differences in programmers? In a factory or call center, the worker performance is uniform enough to view everything as a common cause, with the goal of reducing variation. In software, you want the opposite - you want to unleash your 10x performers.
I'm interested in your views on this. Again, I'm a huge fan of Deming and have read and applied his ideas throughout my career, but this is a sticking point.
I am going to approach this a bit from the other side. And I'll make it personal, rather than asking a series of indirect questions.
More than once, I've ended up in a position where I've put considerable effort into fixing what are often frankly the shortcomings of other co-workers. Co-workers who sometimes may be observed to be very busy discussing their weekends, or the latest movie, etc.
I've fixed conditions that come about as the employees responsible continue to be rewarded, promoted, etc. -- in short, considered "acceptable".
I tried to do what I felt and what I had been taught was "the right thing".
IN HINDSIGHT: When you find yourself persistently in such conditions, when the problem is not a one-off, GET THE FUCK OUT. Unless you can very demonstratively take control of the situation -- of the conditions -- and steer it in a better direction, you are caught in a system that will chew you up at the least and most likely, sooner or later, spit you out.
As a relatively unempowered employee, the single solution to bad management and counter-productive compensation, is to GET THE FUCK OUT.
Anything that prevents your mobility, e.g. employer-provided health insurance, a non-liquid mortgage -- I won't, I refuse to, add "a family" to this list. But otherwise, any such thing becomes an anti-pattern.
One perspective on what is wrong with U.S. society these days: So many people locked into anti-patterns.
The answer to your pains, and how it relates to the article and its insights, is that culture is a system.
In fact, I'd go so far as to say culture is the root of the organizational tree. It's underground and most organizations sort of ignore it, or worse, treat it like it was a hypothetical illusory nuisance they have to lie about to attract rockstars. Ugh.
So culture is the root of the system. It defines how people work together, and how people and work are treated. Culture defines the unseen and unmeasurable motivations people rely upon, without which you get exactly the problems you describe: lack of common purpose, lack of knowledge of process, lack of improvement, infighting, game playing, reward seeking. These are all cultural problems.
I wholeheartedly agree that this is a sign of major problems in perspective in the US. The anti-pattern here is individualistic-dominated thinking, which doesn't accurately describe or solve the problems of an organization of more than one person. It's actually painful to watch corporate culture in this country if you have an understanding of systems design and process control, and especially if you apply it to the human systems of which we are all a part. Science has the answers, but no one cares. Painful.
I think you're actually talking about a very different situation than the source.
The source is dealing with subordinates in each case while you're dealing with peers.
I've been in both positions.
In the case of co-workers whom you have little or no influence over, yeah "get the fuck out" is likely great advice.
In the case of subordinates, or any situation where you have the power/latitude to address things from the top down it makes sense to address the processes in place.
That said, sometimes the process that needs addressing is the identification, swift firing and future avoidance of individual bullshitters and assholes.
This post hit home for me. I've personally implemented code review strategies which directly and immediately led to much improved code quality and generally better product. But management doesn't see code quality. They see deadlines. The insignificant time it takes for code review is the first thing that gets nixed by non-technical management even when the time required for bug fixes, last-minute changes due to their own indecisiveness, and slow development due to giving employees second-rate hardware far eclipse the marginal time it takes to make sure we're deploying halfway decent code to production. And then they bitch at the engineers that they're underpaying/overworking when shit stops working. But let's not hire more developers and improve salaries for the people we have. No, that's not what we need. What we need is more charismatic biz-dev bros with poly-sci degrees. Surely that will fix things! (/rant)
The word "non-technical" seems generous. How about newb or non-functioning or subhuman? Systems are great, but as you point out it's really the people that matter.
> The insignificant time it takes for code review is the first thing that gets nixed by non-technical management
You have to fight back against that shit. Testing, reviews, these things are part of the job. You're the expert, you tell them how long it takes to do things. Don't let them just hand you a deadline without saying something. Speak up!
I agree 100%, and am especially excited to see automated testing as going from "impossible dream" (c. 1999) to "reasonable, broadly expected quality practice". It has been a long road.
However, there's one obvious problem that isn't mentioned: hiring mercenaries half-way around the world who have never met you, don't care about you, don't care about your product, and don't care about your audience.
I think it can be ok to do that sometimes, but it's idiocy to do that and expect to work in the same way as having a permanent employee who sits next to you and who will lose their job if the business fails.
Software developers, even the ones 8 time zones away, are actual human beings not coding robots with coin slots in their chests. If you are going to strip out all of the human connection and replace it with 3 milestone payments plus some spec documents, you can't expect them to care beyond what's necessary to cash the checks. (They might anyhow, out of a sense of professionalism, but you can't expect it.)
The only contracting or remote-team situations I've seen work even moderately well have done a lot to create real human connection.
Such a situation may enhance the issue the author addresses, but his point remains paramount: don't expect what you don't inspect. If anything, hiring "mercenaries half-way around the world" requires more of what he enumerates, which is the objectively practical form of, as you say, "do a lot to create real human connection".
Code review ranks just behind design review in value (cost/time savings). In fact code reviews are so beneficial that if I was working on a solo project I would either pay for them to be done or review the code myself after a suitable cooling off period, depending on what I was working on.
On the other hand, I have also witnessed sloppy, lazy code reviews that catch nothing except the occasional typo. This amounts to an unjustifiable waste of time. Fortunately, it is easy to tell a good code reviews from bad by tracking defect discovery and digging into review comments as needed.
One thing that code review catches that nothing else does is code that is poorly written but functional (i.e. passing tests).
The example I always trot out is
for ( int i=0 ; i < this.MyControl.TabPages.Count ; i++ )
{
this.MyControl.TabPages.Remove ( this.MyControl.TabPages[i] );
i--;
}
This code works according to spec, passes all the tests, but is bordering on unmaintainable. At best it's a WTF.
I find that one of the causes for wildly different levels of code review (and value derived from them) is a lack of training. There is a real lack of materials for explaining how to do a code review, how to do deal with the human aspect of giving feedback, what is/is not valuable to talk about (arguing over tabs vs spaces should not happen in a code review). Most of my experiences have involved a trial-by-fire process - new engineers receive a few code reviews from more experienced people and that is your "training".
Consulting has its challenges, but one of the most amazing perks is charging for value, not time. Once I demonstrate the value of the project to the client, and bill by the week, I no longer have to justify unit testing, continuous integration, code reviews, or any other productivity decision as a tech lead. I know these are the best ways to achieve consistent long-term productivity, and so that's what we do.
Learning how to sell results has not only made me more money, but a better technologist.
Yeah, code review is great...until you find out that some of your reviewers are rubber-stamping the commits from their favorites, and a large percentage of the rest are doing a sub-standard job of reviewing, and pretty much everyone is just barely finding the time to do the (decidedly un-fun) chore of reviewing code, instead of writing code. So you're back to the root cause of the problem: you have to hire good people.
Truly careless employees will (ironically) work hard to find ways around any system that you put in place to prevent carelessness. There are no magic bullets.
Great read. This sentence sums it up best I think, "Why, why, why would people expect to get great results if they flaunt all the best-practices that have developed over the past 20 years?"
I don't think he's using the word "flaunt" correctly. It struck me as off -- sure enough, the definition agrees with me.
"Flaunt: to parade or display... conspicuously. The use of 'flaunt' to mean 'to ignore or treat with disdain' is strongly objected to by many usage guides.'"
Ok, I will go out on a limb here and say that I don´t unit test (at the moment), as I estimate it would take at least twice as long to write the test code and data as the actual code, as there are many related objects that need to be put together correctly for each test case. I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta testers to tell me when things go wrong.
Now I see that unit testing would have caught a few of the bugs over the last couple of years (but not that many of them) but in our case, adding new features and adjusting the data model to the constantly changing requirements is more important. My code does get tested, just not automatically.
I am not saying that it is a bad idea to unit test, and that I never intend to use it, but for the time being the time costs don´t outweigh the benefits.
Also whenever I look at tutorials there is no advice on how to test the parts I want to test. Instead they demonstrate how to test 2 + 2 = 4. I don see the point in that when my application is mainly outputting a moderately complex SQL query results. I can generate a load of objects in the database, and set up unit tests, and have them run each time I update a completely unrelated part of the application, or I can use the real data, and check the results are as expected on my development machine. I know which way is more productive for me.
I think these are all fantastic things to implement but do you know how much pushback you get from engineers on this:
Me: "Do you have a standup every morning, so that you know about schedule delays after at most one day?"
In general folks HATE these, but I would love to hear other cases where people have found them successful. We are small enough that the conversation is ongoing so haven't needed to implement it.
What I have done in other cases is the "walk-around" to speak to people individually rather than in a massive group meeting - and that seems to have been well received.
That said, we often have to take things "offline" because they spur plenty of larger cross-dev, cross-functional discussions. Also, I've made a point of documenting my daily work effort, so I have plenty to report.
I hypothesize that one's enjoyment of daily stand-ups is a function of (a) the team's general openness to communication, and (b) the degree to which one's daily report reflects positively of their effort.
I hate it because some people on the team come in at 6, others come in at 9:30, and anything in between. Some leave by 3:30, and others leave from 5 to 7 pm. I was at work last night until 11:30, working on a particularly gnarly task. (different schedules, because different lifestyles, different obligations -- remember, diversity is good).
When we need to talk to people to find out what's going on, we just talk to them.
I've done daily stand-ups under the Scrum methodology that the whole team liked and found successful. In my experience, it goes best if the emphasis is strongly focused on getting the team members to communicate to each other and to the team as a whole. If everyone is just standing around waiting for their turn to deliver status to the boss, the stand-up is a poor use of time since, as you suggest, the boss could just do the walk-around and collect that status one-on-one. When I've been "scrum master", I make sure the boss/customer/product owner stays quiet in the stand-ups and nudge the team culture towards using the time for the team to talk to itself, synchronize everyone's knowledge and expectations, and build coherence and comraderie, ideally ignoring the extra people in the room.
It's definitely work to build and maintain that kind of culture, but I've had many people tell me it makes them want to come to work in the morning because they enjoy starting off this way. It also helps that I try very hard to make sure this is the one and only recurring "meeting" they have.
So basically you want to implement Enterprise QA processes for a tiny team so as to make up for incompetence and bad hiring decisions. Sorry, I don't buy it.
Unit tests and basic code reviews aren't exactly exclusive to enterprise-level system architecture these days.
Regarding unit tests, their utility is actually mostly independent of the size of the team. The more relevant factor is the size of the codebase. A small team can end up producing a pretty huge codebase, and solid unit tests can end up saving a lot of frustration in the future. They also can be critical in helping new developers familiarize themselves with the codebase and its interdependencies.
Code reviews are an investment not just in the code and the product but also in the human capital producing it. One thing you'll learn with experience is that even very good developers will write bad code sometimes. If you've got millions of users, simply doing code reviews can be a lot less stressful than finding small mistakes later on when bugs pop up in production and a hotfix has to be pushed. It leads to less blame, fewer production bugs, and a more collaborative, academic environment. People can learn and grow a lot from code reviews (both receiving and giving). They'll improve the product and codebase not just in the short term, but doubly so in the long run.
Yep. I don't think doing an 'art review' is going to turn many amateur painters into a picasso.
Code reviews also suck up time of your most senior people. Personally, I'd rather just have some fucking TESTERS. (manual or automatic script writers).
I definitely agree with all of the sentiments in the blog post. With the exception of daily scrum (we do twice weekly), we try to follow all of these habits. There always seem to be two things which we run into though; superficial code reviews and haphazard integration.
On the code review side, I find that most engineers look for trivial crap that could normally be picked up by running lint. It's nice to have similar lint-y style, but for me, the most important things to look for are whether the code is going to break with unexpected input (ie. is the logic sound and are the unit tests good enough), and did the engineer write in an idiomatic style which would be easy for other engineers to understand. I don't mind comments like "maybe use this other variable name", however using recognizable patterns which allow other engineers to easily follow the logic is much more important. Often it seems like people get lazy during reviews and write really superficial comments instead of taking the time to really get down and dirty in another person's code.
And why would they? They've got their own code to write.
The other thing I feel like I'm always up against, particularly with younger engineers (sorry younger engineers!) is not thinking through all of the integration points when your code needs to work with other code which is being developed concurrently. One engineer will say something like "Oh, just call function X", which when you do, doesn't provide the functionality which the other engineer was claiming it had. That, or there was some additional step which one engineer wasn't being explicit about and there was an assumption that you were going to take care of it. There's nothing worse than finding this out on the last day of the sprint when you're trying to button everything up.
There are lots of software developers out there, that shouldn't be developing software in first place. They could be excellent farmers, musicians, athletes, but for whatever reason they decided to be software developers. And it doesn't matter how many scrums or code reviews you throw at them, they just won't get it. They will be producing miserable results making everyone around them miserable.
On the other hand, there still are a few decent, old school devs, who don't need hand-holding, constant poking and distraction of standup meetings and writing meaningless test cases that check if 2+2 is still 4. They just (1) understand the problem and (2) write code that solves it. As simple as that. Good old engineering, like these guys: http://www.youtube.com/watch?v=8kUQWuK1L4w. Or original SAS system - its reference manual was better quality then any statistics textbook. Unfortunately those days are gone now and we live in the kingdom of Scrums and Frameworks.
This may not be obvious to some people (like my boss), but code reviews alone is insufficient; having a good technical design early on is more important.
I've sat through several "code reviews" and they're always conducted at the end of small-ish projects and when I look at the code, I would very much want the guy to rewrite it but by then it would have been too late.
I feel like we're not getting the whole story. For example, what do you do when you follow all these best practices, but end up with a product that no one wants?
I know that these points are often touted as best practices. I agree with most.
I have _never_ seen useful (daily especially!) standup meetings.
That very well might be a cultural problem or an issue with the people I work with etc., but even after giving the idea a couple of chances: 'Daily standups' make me cringe inside.
Building automated test is like getting a flywheel going. Sure it might be difficult to start, but once it's gets going, it will take you very far with little incremental effort.
[+] [-] calinet6|12 years ago|reply
Just as in manufacturing, you cannot produce quality by blaming the individual worker. Japanese manufacturers learned this from W. Edwards Deming (http://en.wikipedia.org/wiki/W._Edwards_Deming) and it continues to be true to this day, but for some reason the natural human instinct is to blame the individuals instead of the systems.
Improve your individuals and you can improve your quality maybe twofold, threefold at best. You might chance upon a "rockstar," but probably not.
Worse, blame your individuals and you lose productivity, lose trust, lose culture, instill fear, and break ties. Negative reinforcement brings unpredictable negative consequences.
Improve your systems, your culture, your process, your communication, and everything surrounding the production of your product, and you can improve your quality tenfold or more, and more importantly, be better prepared for a 100x or 1000x growth.
Blame your systems and they can only get better.
I can't think of a time when it's incorrect to think from a systems-first perspective.
[+] [-] thirdtruck|12 years ago|reply
We're feeling a lot of pressure at my workplace, especially for a team of new hires that only formed less than 90 days ago. We've barely had a chance to get a handle on this legacy codebase or form habits, never mind start cranking out new features right away.
I don't expect a factory to produce maximum widgets halfway through its own construction process.
[+] [-] mathattack|12 years ago|reply
One question that I've had applying him to software, though, is how you align his concepts on systemic defects (most defects are common causes) with the high variety of performance differences in programmers? In a factory or call center, the worker performance is uniform enough to view everything as a common cause, with the goal of reducing variation. In software, you want the opposite - you want to unleash your 10x performers.
I'm interested in your views on this. Again, I'm a huge fan of Deming and have read and applied his ideas throughout my career, but this is a sticking point.
[+] [-] pasbesoin|12 years ago|reply
More than once, I've ended up in a position where I've put considerable effort into fixing what are often frankly the shortcomings of other co-workers. Co-workers who sometimes may be observed to be very busy discussing their weekends, or the latest movie, etc.
I've fixed conditions that come about as the employees responsible continue to be rewarded, promoted, etc. -- in short, considered "acceptable".
I tried to do what I felt and what I had been taught was "the right thing".
IN HINDSIGHT: When you find yourself persistently in such conditions, when the problem is not a one-off, GET THE FUCK OUT. Unless you can very demonstratively take control of the situation -- of the conditions -- and steer it in a better direction, you are caught in a system that will chew you up at the least and most likely, sooner or later, spit you out.
As a relatively unempowered employee, the single solution to bad management and counter-productive compensation, is to GET THE FUCK OUT.
Anything that prevents your mobility, e.g. employer-provided health insurance, a non-liquid mortgage -- I won't, I refuse to, add "a family" to this list. But otherwise, any such thing becomes an anti-pattern.
One perspective on what is wrong with U.S. society these days: So many people locked into anti-patterns.
[+] [-] calinet6|12 years ago|reply
In fact, I'd go so far as to say culture is the root of the organizational tree. It's underground and most organizations sort of ignore it, or worse, treat it like it was a hypothetical illusory nuisance they have to lie about to attract rockstars. Ugh.
So culture is the root of the system. It defines how people work together, and how people and work are treated. Culture defines the unseen and unmeasurable motivations people rely upon, without which you get exactly the problems you describe: lack of common purpose, lack of knowledge of process, lack of improvement, infighting, game playing, reward seeking. These are all cultural problems.
I wholeheartedly agree that this is a sign of major problems in perspective in the US. The anti-pattern here is individualistic-dominated thinking, which doesn't accurately describe or solve the problems of an organization of more than one person. It's actually painful to watch corporate culture in this country if you have an understanding of systems design and process control, and especially if you apply it to the human systems of which we are all a part. Science has the answers, but no one cares. Painful.
Read up and spread the systems knowledge: http://en.wikipedia.org/wiki/W._Edwards_Deming
[+] [-] incision|12 years ago|reply
The source is dealing with subordinates in each case while you're dealing with peers.
I've been in both positions.
In the case of co-workers whom you have little or no influence over, yeah "get the fuck out" is likely great advice.
In the case of subordinates, or any situation where you have the power/latitude to address things from the top down it makes sense to address the processes in place.
That said, sometimes the process that needs addressing is the identification, swift firing and future avoidance of individual bullshitters and assholes.
[+] [-] pvnick|12 years ago|reply
[+] [-] mathattack|12 years ago|reply
Are the managers who don't like this just non-technical? Or are they just not being presented the value in a clear enough way?
[+] [-] 0xdeadbeefbabe|12 years ago|reply
[+] [-] vinceguidry|12 years ago|reply
You have to fight back against that shit. Testing, reviews, these things are part of the job. You're the expert, you tell them how long it takes to do things. Don't let them just hand you a deadline without saying something. Speak up!
[+] [-] wpietri|12 years ago|reply
However, there's one obvious problem that isn't mentioned: hiring mercenaries half-way around the world who have never met you, don't care about you, don't care about your product, and don't care about your audience.
I think it can be ok to do that sometimes, but it's idiocy to do that and expect to work in the same way as having a permanent employee who sits next to you and who will lose their job if the business fails.
Software developers, even the ones 8 time zones away, are actual human beings not coding robots with coin slots in their chests. If you are going to strip out all of the human connection and replace it with 3 milestone payments plus some spec documents, you can't expect them to care beyond what's necessary to cash the checks. (They might anyhow, out of a sense of professionalism, but you can't expect it.)
The only contracting or remote-team situations I've seen work even moderately well have done a lot to create real human connection.
[+] [-] ctdonath|12 years ago|reply
[+] [-] lewaldman|12 years ago|reply
[+] [-] KiwiCoder|12 years ago|reply
On the other hand, I have also witnessed sloppy, lazy code reviews that catch nothing except the occasional typo. This amounts to an unjustifiable waste of time. Fortunately, it is easy to tell a good code reviews from bad by tracking defect discovery and digging into review comments as needed.
One thing that code review catches that nothing else does is code that is poorly written but functional (i.e. passing tests).
The example I always trot out is
This code works according to spec, passes all the tests, but is bordering on unmaintainable. At best it's a WTF.(Written up here: http://cvmountain.com/2011/09/whats-wrong-with-this-code-rea...)
[+] [-] swanson|12 years ago|reply
[+] [-] redthrowaway|12 years ago|reply
[+] [-] nthj|12 years ago|reply
Learning how to sell results has not only made me more money, but a better technologist.
[+] [-] timr|12 years ago|reply
Truly careless employees will (ironically) work hard to find ways around any system that you put in place to prevent carelessness. There are no magic bullets.
[+] [-] shalmanese|12 years ago|reply
[+] [-] mathattack|12 years ago|reply
Quality must be designed in, but people won't do the effort if it's not valued.
[+] [-] 16s|12 years ago|reply
[+] [-] beachwood23|12 years ago|reply
"Flaunt: to parade or display... conspicuously. The use of 'flaunt' to mean 'to ignore or treat with disdain' is strongly objected to by many usage guides.'"
http://dictionary.reference.com/browse/Flaunt
[+] [-] collyw|12 years ago|reply
Now I see that unit testing would have caught a few of the bugs over the last couple of years (but not that many of them) but in our case, adding new features and adjusting the data model to the constantly changing requirements is more important. My code does get tested, just not automatically.
I am not saying that it is a bad idea to unit test, and that I never intend to use it, but for the time being the time costs don´t outweigh the benefits.
Also whenever I look at tutorials there is no advice on how to test the parts I want to test. Instead they demonstrate how to test 2 + 2 = 4. I don see the point in that when my application is mainly outputting a moderately complex SQL query results. I can generate a load of objects in the database, and set up unit tests, and have them run each time I update a completely unrelated part of the application, or I can use the real data, and check the results are as expected on my development machine. I know which way is more productive for me.
[+] [-] AndrewKemendo|12 years ago|reply
Me: "Do you have a standup every morning, so that you know about schedule delays after at most one day?"
In general folks HATE these, but I would love to hear other cases where people have found them successful. We are small enough that the conversation is ongoing so haven't needed to implement it.
What I have done in other cases is the "walk-around" to speak to people individually rather than in a massive group meeting - and that seems to have been well received.
[+] [-] thirdtruck|12 years ago|reply
That said, we often have to take things "offline" because they spur plenty of larger cross-dev, cross-functional discussions. Also, I've made a point of documenting my daily work effort, so I have plenty to report.
I hypothesize that one's enjoyment of daily stand-ups is a function of (a) the team's general openness to communication, and (b) the degree to which one's daily report reflects positively of their effort.
[+] [-] chris_mahan|12 years ago|reply
When we need to talk to people to find out what's going on, we just talk to them.
[+] [-] cja23|12 years ago|reply
It's definitely work to build and maintain that kind of culture, but I've had many people tell me it makes them want to come to work in the morning because they enjoy starting off this way. It also helps that I try very hard to make sure this is the one and only recurring "meeting" they have.
[+] [-] Pxtl|12 years ago|reply
[+] [-] adeptus|12 years ago|reply
[+] [-] nilkn|12 years ago|reply
Regarding unit tests, their utility is actually mostly independent of the size of the team. The more relevant factor is the size of the codebase. A small team can end up producing a pretty huge codebase, and solid unit tests can end up saving a lot of frustration in the future. They also can be critical in helping new developers familiarize themselves with the codebase and its interdependencies.
Code reviews are an investment not just in the code and the product but also in the human capital producing it. One thing you'll learn with experience is that even very good developers will write bad code sometimes. If you've got millions of users, simply doing code reviews can be a lot less stressful than finding small mistakes later on when bugs pop up in production and a hotfix has to be pushed. It leads to less blame, fewer production bugs, and a more collaborative, academic environment. People can learn and grow a lot from code reviews (both receiving and giving). They'll improve the product and codebase not just in the short term, but doubly so in the long run.
[+] [-] penguindev|12 years ago|reply
Code reviews also suck up time of your most senior people. Personally, I'd rather just have some fucking TESTERS. (manual or automatic script writers).
[+] [-] Patrick_Devine|12 years ago|reply
On the code review side, I find that most engineers look for trivial crap that could normally be picked up by running lint. It's nice to have similar lint-y style, but for me, the most important things to look for are whether the code is going to break with unexpected input (ie. is the logic sound and are the unit tests good enough), and did the engineer write in an idiomatic style which would be easy for other engineers to understand. I don't mind comments like "maybe use this other variable name", however using recognizable patterns which allow other engineers to easily follow the logic is much more important. Often it seems like people get lazy during reviews and write really superficial comments instead of taking the time to really get down and dirty in another person's code. And why would they? They've got their own code to write.
The other thing I feel like I'm always up against, particularly with younger engineers (sorry younger engineers!) is not thinking through all of the integration points when your code needs to work with other code which is being developed concurrently. One engineer will say something like "Oh, just call function X", which when you do, doesn't provide the functionality which the other engineer was claiming it had. That, or there was some additional step which one engineer wasn't being explicit about and there was an assumption that you were going to take care of it. There's nothing worse than finding this out on the last day of the sprint when you're trying to button everything up.
[+] [-] shitgoose|12 years ago|reply
On the other hand, there still are a few decent, old school devs, who don't need hand-holding, constant poking and distraction of standup meetings and writing meaningless test cases that check if 2+2 is still 4. They just (1) understand the problem and (2) write code that solves it. As simple as that. Good old engineering, like these guys: http://www.youtube.com/watch?v=8kUQWuK1L4w. Or original SAS system - its reference manual was better quality then any statistics textbook. Unfortunately those days are gone now and we live in the kingdom of Scrums and Frameworks.
[+] [-] zxcvgm|12 years ago|reply
I've sat through several "code reviews" and they're always conducted at the end of small-ish projects and when I look at the code, I would very much want the guy to rewrite it but by then it would have been too late.
[+] [-] 0xdeadbeefbabe|12 years ago|reply
[+] [-] buckbova|12 years ago|reply
Management keeps asking we do them but doesn't enforce it.
Developers don't want to do it and take it personally when you suggest a different approach during the review.
Management sets deadlines on projects without consulting leads or architects.
I (database architect) have suggested we add steps for technical approval and code reviews to our feature/bug tracking system but have been ignored.
I'm sure people can relate out there.
[+] [-] chris_mahan|12 years ago|reply
[+] [-] darklajid|12 years ago|reply
I have _never_ seen useful (daily especially!) standup meetings.
That very well might be a cultural problem or an issue with the people I work with etc., but even after giving the idea a couple of chances: 'Daily standups' make me cringe inside.
[+] [-] medius|12 years ago|reply
[+] [-] binarysolo|12 years ago|reply
[+] [-] ianmcgowan|12 years ago|reply
http://www.joelonsoftware.com/articles/fog0000000043.html
[+] [-] hcarvalhoalves|12 years ago|reply