What if you were on the Starship Enterprise and the warp coil was seconds away from an anti-matter explosion and all you needed to do was invert one IF statement to save the ship. Would you use TDD for that?: Yes.
The article embodies what I see as the biggest problem with Test Driven Development's evangelism: it's full of religious zeal, but short on real-world numbers.
Which situation would your rather be in: risking $100,000 investment for a $200,000 return, or risking $1,000,000 investment for a $50,000,000 return? This might seem like a self-answering question, but virtually all programming hires fall into the first category.
The rebuttal from the first comment is by far more interesting that the article itself:
I will counter with this -- what if I could invest 1 dollar to get a possible return of 206,000,000 ... the lottery is an AWESOME INVESTMENT... wait, odds of success matter, dam
I settled on combining all forms of input into a single system event queue, similar to the windows message queue. My original intention was to just rigorously define where certain functions were called and cut down the number of required system entry points, but it turned out to have much stronger benefits.
With all events coming through one point (The return values from system calls, including the filesystem contents, are "hidden" inputs that I make no attempt at capturing, ), it was easy to set up a journalling system that recorded everything the game received. This is very different than demo recording, which just simulates a network level connection and lets time move at its own rate. Realtime applications have a number of unique development difficulties because of the interaction of time with inputs and outputs.
Transient flaw debugging. If a bug can be reproduced, it can be fixed. The nasty bugs are the ones that only happen every once in a while after playing randomly, like occasionally getting stuck on a corner. Often when you break in and investigate it, you find that something important happened the frame before the event, and you have no way of backing up. Even worse are realtime smoothness issues - was that jerk of his arm a bad animation frame, a network interpolation error, or my imagination?
Reading the archive of John Carmack's aaaa.plan files files a bit like archeology of programming and game design. I still remember playing the games he was writing at the time.
Frequent insights about programming are intertwined with boring parts concerning tuning and racing with his Ferrari cars.
In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range.
How Google uses statistics to find troublesome places in the code.
After we committed to the decision, we handled the move to Git slowly and delicately for a few reasons. One is that we deploy around 30 times a day across an engineering organization that was about 80 people at the time. We didn’t want to lose any of that velocity (we knew we might lose some in the beginning, but wanted it to be as seamless as possible). Another was that we had a varying range of Git familiarity across the team. From Git experts to people who had never touched it. Education played a huge part in our successful transition. It was also important for us to continue the use of flagging code on/off and having a continuously deployed trunk mentality even after the switch to git.
It's seems that people at Etsy know what they're doing. The blog is worth subscribing, if you're a software engineer.
Jack is a Rockstar. Jack talks about all the latest trends at all the coolest conferences around the world. Jack makes a point of starting each project with at least three new technologies. When asked to produce an internet-based backend for letting kitchen devices synchronize their list of recipes, Jack went to town. The result was a combination of Google Protocol Buffers, node.js, and Cassandra. Elegant, scalable, and totally unmaintainable.
Joel Spolsky nailed down the essence of good technical hiring in the title of his book: Smart and Get Things Done. Developers themselves tend to admire “smart” over “getting things done”. This article offers a counter perspective to that.
Rich is concerned, and rightly so, that we have a culture of complexity. That when programmers are given a task, they race ahead and write masses of tangled code, using “easy” frameworks and tools, without giving the problem due thought. That we confuse easiness, with simplicity. (e.g. Rails is easy, it is not simple.) His complaint about tests is that we used them to replace thought. That we feel good about ourselves because we’ve written tests, and yet we haven’t actually given the time to the problem that the problem deserves. We haven’t made the problem simple. We’ve just done what was easy.
Sometimes overlooked negative consequences of agile practices on design.
In 1973, an operating system called CP/M was born. CP/M had no directories, and filenames were limited to 8.3 format. To support input and output from user programs, the pseudofilesCOM1,COM2,COM3,COM4,LPT1,LPT2,CON,AUX,PRN, andNULwere provided.
Code archeology or the story of almost 40 year old legacy carried through generations of Microsoft products to ASP.NET.
In this video, Chuck Rossi, Facebook’s release engineer, dives into the tools and processes his team uses to make it possible to update Facebook on a daily basis – with rarely a public mishap.
Facebook operations team consist of 3 engineers. The presentation shows tools and practices they employ to manage Facebook's frequent updates.
A couple of weeks ago, I was drinking beer in San Francisco with friends where someone remarked:
“You have too many hipsters, you won’t scale like that. Hire some fat guys who know C++.”
It’s funny but it got me thinking. Who are these “fat guys who know C++”, or as another friend put it, “the guys with neckbeards, who keep Google’s servers running”? And why is it that when you meet one, it’s like pulling on a thread, and they all seem to know each other?
A romantic vision of who these “fat guys” are.
