This post has been sitting in my drafts folder for ~3 years. Don’t know why I didn’t post it, it’s not terrible…

When I was in college, I took a Cobol course. It seemed like a good idea because Y2K was coming. There was tons of media buzz about all of the jobs there would be to fix the broken mainframe code. It certainly wasn’t the worst decision of my life.
The fun thing about Cobol at a university in 1993 was that in order to run your program, you had to submit it as a job to the university’s mainframe. A simple program might not get executed for 5 minutes on a good day. As it got closer to the assignment due date, it might be 10s of minutes or even an hour.
Cobol is a finicky language. You have to format your code precisely to make it work. Formatting matters a lot (those of you who don’t like Python would have HATED Cobol). Simple text editors like Notepad or vi were the only way to edit code, so you didn’t get any help from your tools.
It would be a small miracle if your code worked the first time. So after your result printed, you would have to fix something and try again. Sometimes many times. Writing a simple college assignment program that did trivial text manipulation might take you a few hours.
Since the heyday of Cobol, we have PCs on which we can run our code without waiting in line. We have development environments that can tell us about the obvious problems with our code as we type it. There are various ways to have automated tests run your code every time you save it. Feedback has become immediate.
Because of that rapid feedback loop, we now can write that college assignment text manipulator in minutes. We know it works because we have good means of verifying it. We constantly know we are “building it right”.

In our organizations, have we made the same progress with feedback about “building the right thing”?