I thought this was an interesting presentation by Adrian Cockcroft at Netflix.
I know a lot of people think "DevOps" is a dirty word but the way Adrian describes how it works at Netflix is really interesting. This seems to be the embodiment of the "get out of the engineer's way" approach. And its more of that "speed of iteration wins in the marketplace" mentality I've started to see in the past few years. I liked the OODA loop callout in the slides, too....seems like Adrian might actually know who John Boyd is.
What do my fellow soylenters think? Better to give a developer ownership of the entire lifecycle? Or better to have defined checkpoints and stakeholders to ensure quality and defect prevention/identification?
This discussion has been archived.
No new comments can be posted.
Netflix's Engineering Model: Write Code Really Fast
|
Log In/Create an Account
| Top
| 39 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: 2) by Nerdfest on Monday November 10 2014, @10:55PM
It works quite well if you have an extremely good bunch of developers ... if not, the wheels fall off very quickly. You really need to do continuous refactoring otherwise debt build-up will be the equivalent of "hitting the wall". They must have an exceptional team.
(Score: 0) by Anonymous Coward on Monday November 10 2014, @11:05PM
Give your exceptional team sleep deprivation from working 150 hours a week and your quality will be non-existent when someone snaps and murders everyone. The only safe option is to outsource everything to Asia where the workers can't threaten your life. How else are you going to meet that deadline, Tex?
(Score: 2) by tibman on Tuesday November 11 2014, @12:11AM
How about just deliver the minimum requirements in the first iteration : )
SN won't survive on lurkers alone. Write comments.
(Score: 2) by tonyPick on Tuesday November 11 2014, @07:36AM
It works quite well if you have an extremely good bunch of developers
There's a name for management techniques that work if you have an extremely good bunch of developers - "Almost all of them" :)
(somebody once described it to me as; software management techniques are only worth considering if they "get bad developers to write average code" for this reason.)
(Score: 0) by Anonymous Coward on Monday November 10 2014, @11:15PM
If they can type, they can program-- and the faster the better. [thedailywtf.com]
(Score: 3, Insightful) by fliptop on Monday November 10 2014, @11:15PM
A bad project manager can screw it up either way.
Our Constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other.
(Score: -1, Troll) by Anonymous Coward on Monday November 10 2014, @11:17PM
Aww, did the mean project manager take away your Foosball table, poor baby?
(Score: 0) by Anonymous Coward on Tuesday November 11 2014, @01:34AM
When I went through training to be a project manager one particular data point struck me. It was that less than 35% of all IT projects fail. Even the best project managers do not have successful completion rates past 50%. It can happen for a number of external issues, starvation, competition, and so on. In more static industries with a long history like aerospace of automobiles, the project completion rate is somewhere between 60% and 75%. Again, similar reasons can lead good project developers to fail their purpose.
As a technical person that expects things to get done how could I pursue a career path that will lead me to have success rates porrer than a coin toss even if I am the best IT project manager in the world? That is when it sunk in. Imagine the type of people that are willing to accept such numbers. They certainly aren't the kind of people that are talented in any sort of tech.
(Score: 2) by PizzaRollPlinkett on Monday November 10 2014, @11:20PM
The problem with developers doing everything is a matter of distance from the code. Someone else needs to test and use the software the developer creates because the developer is too "close" to the code to step back and see if the code works or even makes any sense. You get so deep and involved that you don't see what's plainly there, and the next person who comes along finds your screwups instantly. And someone else will use the software in ways the developer never imagined. Developers are carrying too much internal state information in their brains to do everything in the "devops" chain. You need some kind of QA and rollout process to slow things down and catch mistakes.
Then again, just edit the scripts on the production server and hope for the best.
(E-mail me if you want a pizza roll!)
(Score: 0) by Anonymous Coward on Monday November 10 2014, @11:24PM
Great idea! My production server is too stable.
(Score: 2) by Nerdfest on Monday November 10 2014, @11:45PM
rollout process to slow things down
No, you don't need anything to 'slow things down'. QA and testing is one thing, but process intended purely to 'slow things down' is extraordinarily Dilbert-worthy.
(Score: 0) by Anonymous Coward on Tuesday November 11 2014, @12:03AM
Those days are over.
There is no time or money to spare on separate QA with additional people in today's hypercompetitive business environment.
The developer can just cut and paste working code and carefully refactor/re-edit it for new purposes. The only subtle logic errors to watch out for is that all the identifiers are correctly renamed. Once that is done, the code should work on the first try if you wrote and re-edited it carefully in the process.
(Score: 0) by Anonymous Coward on Wednesday November 12 2014, @12:37AM
The developer can just cut and paste working code and carefully refactor/re-edit it for new purposes. The only subtle logic errors to watch out for is that all the identifiers are correctly renamed. Once that is done, the code should work on the first try if you wrote and re-edited it carefully in the process.
This should not be marked as 'funny' - it is what some major software companies are doing today. Scary as hell, but as he says, in this hyper-competitive market, there is no time/money. Doing it 'right' (for your definition of right) will result in you being late to market today, which will kill your future prospects. It no longer matters that you will eventually produce very good, stable, etc. code - if you are late, you are history. Sad state of affairs we've gotten ourselves into!!
(Score: 0) by Anonymous Coward on Tuesday November 11 2014, @12:06AM
Means quick turn around for projects, but also usually means no documentation. So when the team fractures things go off the rails pretty spectacularly.
(Score: 4, Insightful) by tibman on Tuesday November 11 2014, @12:18AM
I am a firm believer in "The code is the documentation." External documentation is (at best) a summarized version of what everyone hopes the code is actually doing. External docs will rot but the code will always tell you the truth. I'm not saying there shouldn't be any docs though. When half the developers get fired, its nice to have some summarizing documents about their projects. But you can't plan anything from those documents. You'll have to read the code.
SN won't survive on lurkers alone. Write comments.
(Score: 3, Insightful) by jcross on Tuesday November 11 2014, @12:40AM
The problem with that approach is that the code itself only specifies what is being done, never why. An outside observer winds up asking: is that just a clever optimization gone wrong, a fix for some quirky bug, or an essential feature for some edge case? If I change this line, what might I break? Maybe best to leave it alone and solve the problem by bolting on some hack or even rewriting the whole thing. Over the years this kind of thing can slow the development of a product to a halt. Also, it's often really hard to get a high-level overview by reading the code; it might need to be synthesized over days or weeks of careful reading and note-taking. And the code may specify the contract it's supposed to uphold at the call-signature level, but not at the level of behavior, especially in edge cases.
Sure, documentation slips away from the code if it's not maintained, but I think it should be maintained as religiously as the code, because anything less introduces a technical debt for your successor or even future-you who has to figure things out. Well-written automated tests are another way to document what the code is expected to do, and allow for fearless refactoring even by someone unfamiliar with the original code. Most of the time spent on a successful piece of software is actually going to be maintenance, but I find few projects are optimized for that.
(Score: 1) by Ethanol-fueled on Tuesday November 11 2014, @02:54AM
Another point with "self-documenting code" is that, if the engineer's a clever dick, he can make it deliberately unreadable to give him job safety under the guise of "speed and efficiency," especially in languages like C where you can code something ruthlessly efficient that reads like a bunch of asterisks and underscores stirred into a ghoulash of punctuation and two-letter variable names and totally untraceable bugs.
The bottom-line is, well, the bottom-line. Doing shit the right way costs money, and documenting code subtracts from the short-term profit.
(Score: 2) by Nerdfest on Tuesday November 11 2014, @05:00AM
That's why we have code reviews. They are not optional. Someone writing obfuscated code gets the boot.
(Score: 1) by Ethanol-fueled on Tuesday November 11 2014, @05:17AM
You're lucky to work for a place that is willing to spend the time and money to do that nowadays.
(Score: 2) by Nerdfest on Tuesday November 11 2014, @03:59PM
Maybe. I consider it "don't have the tome or money *not* to do it". It saves both even in the short term.
(Score: 2) by jcross on Tuesday November 11 2014, @04:00PM
I'm contemplating an entry into the IOCC where the code doesn't look obfuscated at all. It's so easy to make code unreadable using machine obfuscation that now the top entries focus on making it into a picture of a fox jumping over a dog or whatever. But what would be really challenging is to make it look like the code does something straightforward, but actually via subtle "mistakes" it's doing something totally different. The NSA probably has a whole bunch of people doing that already, I bet, but it would be fun to see how far you could take it.
(Score: 2) by urza9814 on Wednesday November 12 2014, @07:12PM
There's already an entire contest dedicated to that too -- The Underhanded C Contest.
(Score: 2) by jcross on Thursday November 13 2014, @02:10PM
Oh yeah, I'd forgotten about that one. Thanks!
(Score: 0) by Anonymous Coward on Sunday November 16 2014, @12:26PM
x3L49D rpmqxzudvlnd [rpmqxzudvlnd.com], [url=http://vrfwivhixdua.com/]vrfwivhixdua[/url], [link=http://oecitcfhlari.com/]oecitcfhlari[/link], http://mlmfrbbhepgc.com/ [mlmfrbbhepgc.com]
(Score: 2, Informative) by itn on Tuesday November 11 2014, @09:05AM
I agree with rest of what you say, but
The problem with that approach is that the code itself only specifies what is being done, never why. An outside observer winds up asking: is that just a clever optimization gone wrong, a fix for some quirky bug, or an essential feature for some edge case? If I change this line, what might I break?
Isn't that why you comment the code, especially the clever optimizations, fixes for quirky bugs and edge cases?
(Score: 2) by black6host on Tuesday November 11 2014, @10:46AM
Exactly. I go even further. The code should document itself. Comments are to explain why something works the way it does. Maybe they're business rules. Or perhaps special functions used in observing our world. Or have any other reason for existence. Write the code to document what it's doing, comment why it's doing it.
(Score: 2) by jcross on Tuesday November 11 2014, @03:53PM
Absolutely! For me comments *are* the documentation, or at least the best and most important kind, since it's easy to fix them when you fix the code. I've seen people argue for commenting infrequently based on a straw man like this:
// increment i
i++;
Which is indeed redundant. But this is not so redundant:
// advance to the next patient record
i++;
At the bottom of a long loop, it might be easy to forget what the ubiquitous "i" means. Yes, the code can and should be written so as to make itself as clear as possible, but there's a limit to how far you can go in that direction, because code has a fundamentally different logic from human language.
(Score: 2) by tibman on Tuesday November 11 2014, @02:43PM
Dude, automated tests! Most people ignore this aspect and i'm usually shot down for suggesting it. At work i'm allowed to TDD. I think it's slower but it certainly gives you fearless refactoring. You can also safely poke at someone's confusing optimization. Its the best answer for edge case code too, imo. If you want to know why any line exists you can use your code-coverage tool to show you what tests are covering that line. Or just delete it and see what tests fail : )
I completely agree with you that most projects are not designed to be maintained. Unit tests are a great long-term maintenance tool.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by jcross on Tuesday November 11 2014, @04:02PM
TDD is the shit! It only seems slower at first, but over time it allows a small team to maintain and improve a massive amount of code. It's like the opposite of technical debt; technical capital or something.
(Score: 0) by Anonymous Coward on Sunday November 16 2014, @07:11AM
pH2IU2 ltbdvuezdens [ltbdvuezdens.com], [url=http://rljxsqrurlzf.com/]rljxsqrurlzf[/url], [link=http://egggssdssemt.com/]egggssdssemt[/link], http://cutmnngpvcfz.com/ [cutmnngpvcfz.com]
(Score: 0) by Anonymous Coward on Sunday November 16 2014, @07:44AM
UyLIM5 avifwzzdpjtk [avifwzzdpjtk.com], [url=http://ueyegmatqcza.com/]ueyegmatqcza[/url], [link=http://klozqmamtcws.com/]klozqmamtcws[/link], http://rkzqaihhrpys.com/ [rkzqaihhrpys.com]
(Score: 2) by Non Sequor on Tuesday November 11 2014, @12:55AM
I don't think that's even a word.
Write your congressman. Tell him he sucks.
(Score: 2) by c0lo on Tuesday November 11 2014, @04:49AM
Perhaps it's an odd (like in not even?) word for you but it exists [wikipedia.org]. My current job falls into this category.
(maybe you should have stopped after the first 3 words??)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by VLM on Tuesday November 11 2014, @02:55PM
Its a parody word, like "agile", those words don't really mean anything, anymore. Once it may have had meaning, but not today.
"I need to ram thru some fairly obvious, mostly common sense process improvements and departmental reorgs with very stereotypical business goals (better, faster, all the usual suspects) and I'd like my employees to work harder and do more peoples work for the same pay... can't call it agile because we already used that meaningless buzzword... Cloud is getting tired too... I know, we'll call it devops. That'll do for a couple years. In 2016 or so we'll need a new meaningless buzzword but the industry seems to have no problem producing those."
(Score: 2) by c0lo on Tuesday November 11 2014, @11:01PM
With all respect, I disagree in regrads with "no meaning" for devops (I won't comment on "agile").
I find devops a useful term to express a reality in which the applications are adjusted/enhanced/modified, tested, deployed in very short cycles, which involves not only developers by sys /network/database admins. It happens as an everyday mode of life at my current workplace: a research joint, where the researchers need/use application custom developed in-house by a small dev team (about 6) while the rest of the "ops" part is made from about 15 others (network, storage, HPC, phones and A/V equipment, digitally integrated lab equipment, etc).
It's like building a plane around the travellers while in flight.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by VLM on Wednesday November 12 2014, @12:22PM
"very short cycles"
I don't think we're necessarily disagreeing here. "devops" is at least a paragraph, if not entire books, that summarize to "shorten/speedup the cycle".
(Score: 2) by Non Sequor on Wednesday November 12 2014, @02:47AM
That's more or less what I was going for. I'm sure that the handle "DevOps"is attached to something with a rich meaning that its devotees can tell us all about, but words have etymologies, some sort of relationship to things with well understood meanings that lets people understand what the new coinage means without necessarily having to have it explained to them.
Write your congressman. Tell him he sucks.
(Score: 2) by urza9814 on Wednesday November 12 2014, @07:17PM
DevOps = Development and Operations
Seems pretty clear and understandable to me...
(Score: 0) by Anonymous Coward on Tuesday November 11 2014, @05:45AM
They want to DRM the HTML.
https://www.defectivebydesign.org/cancelnetflix [defectivebydesign.org]