Recently a friend said to me, "My remote engineer contractors aren't committed enough. They say they'll get a feature finished by the end of the week, but they don't finish in time! How can I get them to be more committed?"
Another friend said, "My engineers in China are not invested. They're not detail-oriented. Our error rate on the site is insanely high. The engineers just do a half-assed job. I wish I could hire engineers who care more."
A third person said, "My engineer is too young and isn't careful. He doesn't check his work. He lets serious bugs get onto the site."
In all 3 cases, after hearing about how these engineers are careless, I had this exchange:
Me: "Do you do code reviews?"
Friend: "No." (except first friend who does them retroactively after the code is already checked in)
Me: "Do you send out technical designs for review, before you start coding?"
Friend: "No."
Me: "Do you have unittests to catch the regressions?"
Friend: "No, we barely have time to develop the features. We don't have time to write automated tests."
Me: "Do you have manual QA?"
Friend: "No. I try to test the site when I have time."
Me: "Do you have a standup every morning, so that you know about schedule delays after at most one day?"
Friend: "No. We're such a small team. It seems overkill."
Why, why, why would people expect to get great results if they flout all the best-practices that have developed over the past 20 years? And then blame the poor engineer?
Let's say I ask an architect to build a house. But because his hourly rate is expensive, he's not allowed to make a blueprint first, or build a small-scale replica, or to spend time holding discussions with subcontractors. Every minute needs to be spent doing hands-on work on the house. The house ends up being completed late due to re-work, and after being finished, it has all sorts of problems. Do I blame the architect?
Another friend said, "My engineers in China are not invested. They're not detail-oriented. Our error rate on the site is insanely high. The engineers just do a half-assed job. I wish I could hire engineers who care more."
A third person said, "My engineer is too young and isn't careful. He doesn't check his work. He lets serious bugs get onto the site."
In all 3 cases, after hearing about how these engineers are careless, I had this exchange:
Me: "Do you do code reviews?"
Friend: "No." (except first friend who does them retroactively after the code is already checked in)
Me: "Do you send out technical designs for review, before you start coding?"
Friend: "No."
Me: "Do you have unittests to catch the regressions?"
Friend: "No, we barely have time to develop the features. We don't have time to write automated tests."
Me: "Do you have manual QA?"
Friend: "No. I try to test the site when I have time."
Me: "Do you have a standup every morning, so that you know about schedule delays after at most one day?"
Friend: "No. We're such a small team. It seems overkill."
Why, why, why would people expect to get great results if they flout all the best-practices that have developed over the past 20 years? And then blame the poor engineer?
Let's say I ask an architect to build a house. But because his hourly rate is expensive, he's not allowed to make a blueprint first, or build a small-scale replica, or to spend time holding discussions with subcontractors. Every minute needs to be spent doing hands-on work on the house. The house ends up being completed late due to re-work, and after being finished, it has all sorts of problems. Do I blame the architect?
21 comments:
"We don't have time to write automated tests." - my friend, you don't have time NOT to write automated tests!
This is a ridiculous post. Obviously, unit testing, QA's and daily standups are an important part of the development life-cycle.
Is anyone debating this? Is this post written for non-technical people?
Me thinks this post is simply meant to make the author feel really good about herself.
Great post! Back to the basics. If you're not doing the basics and there are problems, start there! Just what I needed to help me on a current project. Thank you.
"This is a ridiculous post. Obviously, unit testing, QA's and daily standups are an important part of the development life-cycle.
Is anyone debating this? Is this post written for non-technical people?"
It's not ridiculous - this is still happening everyday in companies big and small.
The word "flaunt" doesn't mean what you think it means. Perhaps it should be replaced with "disregard".
Not a ridiculous post. The fact that 3 of 3 random people are not following any best practices is informative. Probably the original detractor doesn't even do everything from an even slightly larger list of best practices: http://www.joelonsoftware.com/articles/fog0000000043.html
"Flout". Not "flaunt".
Yes, I meant flout. Thank you!
Wow, are you a bot, Niniane? Your reply was within a few seconds! :)
It's a great article, and I'm glad you wrote it. Often our expectations are not in line with our actions (or is it vice versa?). Thank you for laying this out in a clear manner; I'm hoping lots of team leads will use this as a starting point for self-reflection.
Amen. I work with a lot of different coding contractors -- the ones I enjoy working with are the ones who are already doing these things. For the rest, I may try to find a way to diplomatically point to this post :-)
What she is describing sounds like reality at many places. Not ridiculous at all. There may be many be in IT but you won't find much IT in them.
This stuff happens, all the time, every day. I believe poor Engineering engineering leadership is *endemic* in the Valley, and especially when overstreched teams try and outsource without putting controls in place that will make the relationship more effective and positive for both parties.
That you think these are "best practices" shows how far the art of software development has fallen.
Standup Meetings- wastes of time. If you're putting programmers in pointless meetings you're doing it wrong. This can be accomplished with updating status on issues.
"Unit tests" - make work for big companies. Sure, if you have a public API, then yes, unit tests make sense. Most of the time, unit tests are designed to try and keep JR engineers from making mistakes, but the root cause is bad hiring practices.
Technical Design- yes you should do this, but it should be your engineers doing this. Having engineers just do implementation means you have coders, not engineers. If you don't give them something to engineer, again, you have a hiring problem.
Code Reviews- really depends on how they are done, but good engineers don't need them. Meetings to work out integration of disparate parts, this makes sense. But taking two engineers time where one engineer explains to the other how he did stuff is kinda pointless- either he's competent or he isn't , and a lot of the time, code reviews are an opportunity for less competent engineers to nitpick decent code.
All of this is the worship of process over quality engineering.
These "best practices" are all symptoms of enterprise development trying to compensate for terrible hiring practices.
If you're an engineer with any self respect, you won't work in a shop that follows these practices because they are proof positive that they don't understand or value you.
"These "best practices" are all symptoms of enterprise development trying to compensate for terrible hiring practices."
So you're saying, that assurance of quality and constant client communication, as well as something to automatically catch any obvious regressions is a result of people not being perfect?
You're absolutely correct! We're not perfect! If you go out looking to hire only "perfect" people, you won't have any employees in the first place.
"If you're an engineer with any self respect, you won't work in a shop that follows these practices because they are proof positive that they don't understand or value you."
I'm sorry, I didn't realise that other making my life and job easier meant they didn't care about me. I should leave right away. My apologies.
People make mistakes. Lots of people make mistakes. Lots of people over a long period of time, make mistakes. If you have a team of forty builders and architects building a house, you have processes in place to mitigate any issues and stop them from happening again. While a perfect person may not ever need these, and with smaller teams and project you may not need these, the majority of the time they are a boon, not a hindrance.
If you believe that great client communications and regression testing is a bad thing, and is beneath you, then you'll end up beneath a client's foot.
Man these comments are getting heated! It's not a battle of quality vs productivity. Neither side is perfect. You have to strike a middle ground.
If there was a magic formula to running a software business wouldn't you think everyone would be doing it?
Octane is right, there is no magic formula, but this goes to my point- the post is acting as if there was a magic formula.
And of course InvaderTim's response brings up an important issue that I didn't address: These policies are not being chosen because they work, but because they are part of a fanatical ideology.
Invader Tim is so angry because I dared to point out that the policies actually don't work as expected, and are bandaids for the real problem... which is why, rather than responding to what I did say, he chose to snottily lie about what I said to try and smear it.
When you have people being that irrational... you know you're dealing with an ideology, not "best practices".
I don't know why so many people would be so emotionally invested in processes that make software worse, but they are.
That they cannot tolerate opposition shows that these are not "Best practices" based on results, but an ideology based on emotion.
Also, maybe people get crap results when they outsource jobs to people overseas so they can pay them next to nothing.
> Do I blame the architect?
Sure, but I might rephrase it as "terrible architect hiring practices" to make the scapegoating a little less obvious.
How young and experienced are these folks? If recent grads, only reinforces the fact that experience matters and fresh / recent college hires don't know everything.
On many projects the programmers are so far removed from understanding how the end product should function that many layers of checks need to be in place. (Especially when removed from the process by time zones, having never seen the machine, application, or even the people involved).
On other projects a few engineers "Get" the big picture and very few layers of process control are needed, even if very large in size. I have worked on both types and each can work very well or be disastrous.
Post a Comment