It looks like folks at micro.blog do not test their software 😂

Ship / Show / Ask — Rouan Wilsenach | Martin Fowler:

When talking about patterns for managing source code branches, I used to think as a team, we can either be a “Continuous Integration team” (good) or a “Pull Request Team” (evil).

After reading this great article written by Rouan Wilsenach, I realized there are more nuances in that (or in life frankly), and we don’t have to pick any side. He also went ahead and suggest this Ship/Show/Ask model for anyone to use for communication with our teammates, see where we are at, and working on ways to improve (if needed).

My teams are “Mostly Asking” teams. I will try to nudge ourselves to “Showing more”. I hope to document my experience doing that here as well.

I know a lot of people will hate me for this, but I’m thinking about hosting two talks:

• [my organization] is not “doing DevOps.”
• [my organization] is not doing Continuous Integration (CI).

Or should I find another organization where there would be fewer people hating me for giving those talks?

Testing in the Twenties - Tim Bray:

1. Unit tests are an essential investment in your software’s future.
   
2. Test coverage data is useful and you should keep an eye on it.
   
3. Untested legacy code bases can and should be improved incrementally
   
4. Unit tests need to run very quickly with a single IDE key-combo, and it’s perfectly OK to run them every few seconds like a nervous tic.
   
5. There’s no room for testing religions; do what works.
   
6. Unit tests empower code reviewers.
   
7. Integration tests are super important and super hard, particularly in a microservices context.
   
8. Integration tests need to pass 100%, it’s not OK for there to be failures that are ignored.
   
9. Integration tests need to run “fast enough“.
   
10. It’s good for tests to include benchmarks.
    

I think we’ve just had a new Testing manifesto. Agree with most of the explanations to those ten points too.

Update: There is a great comment from Jim:

I’ve noticed that (the more reasonable of) those of us that are, treat TDD mostly as a design exercise, not a testing one. We just get tests as a bonus. And of course, sometimes the tests need to change, and some I throw away.

I also do “exploratory testing” when trying out new libraries, techniques etc, especially in spikes. I find it helps to keep the crap tests then, as a warning for later :-)

Secondly, I think needing to make private methods public in order to test them is a code smell. Almost all the time, there is another class trying to get out. Somewhat more rarely, there is code in private methods that cannot be exercised by calling the public ones, which means there is unnecessary code in the private ones, and it can safely be removed.

I have very similar thoughts to Jim’s while reading this article.

We should think of TDD as a helpful practice (for some people) to create well-designed, well-tested code instead of considering it “the best and only way to archive self-testing code.”

I do make private methods/properties internal to test their internal state sometimes because it’s easier that way. However, I have to think about those cases a lot and also consider them code smells.

Thanks a lot guys.

Another update: Very quickly, Mr. Fowler himself steps up and publish his take on the subject.

And as usual, he points out the exact problem - very clearly with pictures. Please go ahead and read the whole thing since quoting his entire post would be weird.

Thanks again, guys!

--pink: #b72c31;
--orange: #e36942;
--yellow: #d48207;
--green: #10505b;
--blue: #25476d;
--purple: #353a71;
--silver: #c7c8ca;
--pink-light: #eeb8b0;
--orange-light: #e9aa95;
--yellow-light: #eaca96;
--green-light: #a4beb2;
--blue-light: #a8bed2;
--purple-light: #abacca;

Source: Apple

Kevin Bongart (@KevinBongart):

After 10+ years of using Markdown, it finally clicked that web links usually look like rectangles (on mouse hover), so the text is in brackets. The URL, as an additional detail to what you’re reading, is in parentheses.

This is so useful for anyone trying to write for the web. Mr. Gruber sure put a lot of thoughts and real life experience into designing the Markdown syntax.

Kyle Starr in the thread also thinks the image syntax ![ ]( ) looks like an old press camera.

Thank you guys.

The lack of a price tag seems almost criminal - inessential by Brent Simmons:

I should explain: (NetNewsWire) is better — much better — than it would be if it were a for-pay app. If it were a for-pay app, it would be just me working on it instead of this great team of volunteers. There probably wouldn’t be an iOS version at all: it would be Mac-only. The kind of features I don’t enjoy doing, such as the Twitter and Reddit integration (and others), wouldn’t even exist.

And it would be slow going. NetNewsWire 5 would have shipped much later than it did, and NetNewsWire 6 would not have shipped until next year, probably.

Instead, because it’s open source, we have this amazing team of people willing to work on it in their spare time. During a pandemic and everything. They’re bringing you something great out of love, with the goal of writing an app of the highest quality.

We don’t have to rush and Ship Right Now in order to make our revenue numbers. We don’t have to pick feature X over feature Y because we think it will bring in more conversions. We can care about performance and efficiency; we can say no to things that might have made money but that are outside our vision.

There’s nothing wrong with commercial software — NetNewsWire was commercial software for many, many years — but it’s also a great freedom to us that it’s not. And it allows us to make something much greater than I would have made all on my own.

I have a feeling that this is the exact situation that the great text editor TextMate is in, and they are going in this direction as well.

The sad part is:

(Why all on my own? Because, these days, a Mac and iOS RSS reader is not going to bring in enough revenue to pay for a team greater than one. And even paying one full salary plus health insurance would have been a hell of a longshot.)

Anyway, let’s support NetNewsWire. (Don’t send money!)

inessential: How NetNewsWire Handles Threading:

Some developers I’ve known seem to think that being good at concurrency makes them badass. Others seem to think that senior developers must be great at concurrency, and so they should be too.

But what senior developers are good it is eliminating concurrency as much as possible by developing a simple, easy, consistent model to follow for the app and its components.

See also: Common reasons that software projects fail

Ori And The Will of the Wisps Switch Analysis: Inside An ‘Impossible’ Port:

It must be amazing working on this whole thing, the devs making this sensational port, the guys from Digital Foundry making this video - which is the best video from them so far.

Code Complete: Design in Construction:

Projects fail most often because of poor requirements, poor planning, or poor management. But when projects do fail for reasons that are primarily technical, the reason is often uncontrolled complexity. The software is allowed to grow so complex that no one really knows what it does. When a project reaches the point at which no one completely understands the impact that code changes in one area will have on other areas, progress grinds to a halt.

Using an Agile Software Process with Offshore Development:

Because agile development works best with close communication and an open culture, agilists working offshore feel the pain much more than those using plan-driven approaches. But it’s still less pain than the plan-driven methods themselves!

I can feel the pain myself after just ~3 years in the field.

Toyota Production System - Extreme Programming Explained: Embrace Change, Second Edition [Book]:

If you eliminate enough waste, soon you go faster than the people who are just trying to go fast.

Today is my first day ever working from home, one of the first things I noticed is that Windows 10 looks very crisp on my Macbook Pro (via remote). I have always know that my work monitor is crap but now it’s clearer than ever before.

Another thing is that I thought working from home means that you connect to the company VPN and, you know, work from home. According to my company’s policy, we have to keep our work machine on over the weekend, then at home we will remote access to that machine and “work”. I know outsourcing software means security is the top priority but I would argue that if all the source code is on Gitlab, all tasks are on Jira/Confluence, all designs are on Figma, all resources are on AWS already… is there a better way to work?

Coping with Covid-19, part 2:

Most ThoughtWorkers are young and healthy, thus likely to only have a mild problem if infected with Covid-19. But everyone, healthy or not, who has the virus can pass it on to others. By reducing travel and contact we can do our part to slow the spread of the disease. Even if the total numbers aren’t reduced by a slower spread, it will reduce the strain on the health care infrastructure, giving those unlucky enough to suffer serious consequences a better chance of coping.

This sums up perfectly why we must shut up and stay at home.