Man I don't love these unspecified, context-free takes on "building software". The author lists a lot of tech stack, but no scope, no context, no size estimates about the software he's built.
Now we have a thread where the gal writing FORTRAN for legacy nuclear plants is telling the guy doing IT for a mom and pop how he's approaching tests all wrong. Meanwhile, the third person working in an expanding startup who has "ninja" in his job description understands neither and looks down on both.
I used to be very impressed with people that wrote programming books, spoke at conferences, and so on. Decades on, I look at the best programmers and managers I’ve ever worked with and notice they’ve never done these things. On the flip side people I’ve worked that were always off doing this kind of thing never seemed all that impressive when it came down to building our products and business.
There’s only so many hours in a day—-are you using them to build software or your personal brand?
One engineering leader I worked with lost out in a corporate power struggle and left to “spend more time with his family.” While he was doing that, he produced a series of blog posts. Once he found his next role the posts petered out. This strikes me as a publication model for actual high performers.
It’s tricky to balance Doing Stuff and Broadcasting Stuff.
You need both. If you spend 100% of your time heads down, even delivering huge value, nobody will notice and your career will suffer. If you spend 100% of your time bloviating, you’ll never build anything of value.
As so often in life, I find the best solution is to team up. Partnerships between an 80 build / 20 tell and a 20 Build / 80 Tell change the world. Woz + Jobs is just the best known example.
The book Rocket Fuel calls these “Integrators” and “Visionaries” https://www.eosworldwide.com/rocket-fuel-book
Unless you are building tdd software, you don’t need anyone telling the world your team’s thoughts on tdd. It’s sold as part the recruiting effort, but I’m dubious as to the ROI.
The broader point seemed to be that tests should be treated like an investment that ought to pay off and you shouldn't do it if it doesn't.
I think the author didnt make this point particularly well but I agree with it and I think it does apply equally to building both space rockets and mom and pops.
I think everyone has something in common though - they all think testing is a waste of time until all the sudden things start not working at all and it isn't!
I would consider myself a TDD type of dude, but not in a dogmatic way because to be honest I find the intent and execution to be self evident, but have never really looked into doing it “properly”.
For me, the #1 reason I lean so heavily on tests is that the software I write rarely behaves exactly as I expect and intend. And the beyond that, I will not remember how a piece of code works 6 months or a year from now.
Having tests is an easy way to say “ah, this is how that actually works”. Which is relevant whether you’re trying to identify why an edge case is behaving so weird, or because you forgot or never knew how some bit of code worked.
As a side benefit, I work with some renegades whose bugs are only stoped because CI begs them not to merge their code, which has introduced a sea of red failures. If we didn’t have tests, we’d find out about these issues in a much different way.
I'm anti-dogma for everything in software, but I have been using TDD more than 90% of the time for the last 3 years. I think this is rare, and it works mostly because I don't do it the orthodox way most of the time.
I think orthodox unit test driven development works and works really well about 15-20% of the time - under scenarios where you have stateless code, a simple API with simple inputs and simple outputs and some complex logic underneath it. If you're writing something like a parser, this might be all you need.
I use a more unorthodox version of TDD the other 70-80% of the time, constructing what most other people would regard as a combination of a snapshot test and integration test. It's still TDD, but the test might be something like "load web page, enter text in textbox, click button, fix snapshot of the outcome, faking the REST API that gets called". I find this practice to be vanishingly rare, but I also find it pays large dividends.
The orthodox way to do that other 70-80% of code is to create a mess of mock objects. I don't think the people who came up with TDD necessarily intended this (with the exception of uncle bob), but I think it's responsible for most of why it doesn't work for most people most of the time.
I've worked in start ups where they don't have automated tests.
The code quality is not as good. But that imo is not a symptom of lack of tests. It's a symptom of being a start up and the desire to move fast.
As for mysterious error or bugs that occur the rate at which we get them in the code is no larger than code with tests.
It turns out that manual testing and static checking is mostly enough.
I think for most stuff testing is an illusion. It's one of those faith based mantras developers follow without any basis in science. There are a few applications where I feel automated tests are required but they are not the majority of software projects.
I've worked in plenty too. They start out faster. Delivery and quality both decrease almost imperceptibly for a long period. When somebody who understood how everything was built leaves because they got offered 20% more elsewhere, delivery and quality both plunge quite a lot and the decline accelerates.
It's incredibly unusual for them to recover delivery speed and quality after not doing automated testing for so long. It's incredibly hard to "bolt on" testing afterwards - both because the culture and context isn't there but also because the tooling and infrastructure can't be built up in a week. Most companies in this state look for quick fixes like:
* Elaborate branching strategies
* Entirely different versions of the software for different clients (because you're too afraid to upgrade them all).
* Ever more infrequent releases.
The next step is technical bankruptcy. That's when your devs start whingeing about wanting to do a full rewrite. That's usually the point where you've probably ended up losing money overall by dodging tests.
It can work without tests you manage to hit product/market fit before the decline sets in, but I find that companies in this situation often tend to struggle developing and will often stagnate. 1/50 might tap into some undiscovered new market opportunity and hit it out of the park either way but it's rare.
> It's a symptom of being a start up and the desire to move fast.
My take is that you can only move fast when you are not in a hurry. If you are in a hurry, you need to work slower, or things will be messed up with no time to fix it.
Thus, usually, there is no need to move fast, since if you can, you are not in a hurry anyway.
Now we have a thread where the gal writing FORTRAN for legacy nuclear plants is telling the guy doing IT for a mom and pop how he's approaching tests all wrong. Meanwhile, the third person working in an expanding startup who has "ninja" in his job description understands neither and looks down on both.
Not very productive.