12 Signs You’re Working in a Feature Factory

Are you constantly shipping features and cutting corners? Then you might be working at a Feature Factory. Here are 12 symptoms:

  1. No measurement of impact.
  2. Rapid shuffling of teams and projects.
  3. Success theater around “shipping”.
  4. Infrequent (acknowledged) failures and scrapped work.
  5. No connection to core metrics.
  6. No PM retrospectives.
  7. Obsessing about prioritization.
  8. No tweaking.
  9. Culture of hand-offs.
  10. Large batches.
  11. Chasing upfront revenue.
  12. Shiny objects.

Each bullet is explained a bit more in the post itself.

12 Signs You’re Working in a Feature Factory →

📝 I actually found this post through the follow-up post 12 Signs You’re Working in a Feature Factory — 3 Years Later. Also worth reading.

Good Code Reviews, Better Code Reviews

Gergely Orosz:

Plenty of people and organizations have shared their code review best practices and what the definition of good code reviews mean to them. Below is my personal take on what good code reviews look like and what great ones – better than good – are.

Some very good tips! In my own personal experience: Good PRs and Reviews take time to write. It’s most of the time a very sentimental thing.

Good Code Reviews, Better Code Reviews →

The (fictitious) adventure of learning the next big framework

Installing all the things!

On learning a new framework, and having to install a gazillion things for starters, and then eventually seeing it not work at all:

I just want to write a bit of code and make a simple app,” Roger thought. It shouldn’t be this hard.

Still, he didn’t quit. He cut and pasted each and every console error into Google. He discovered on Stack Overflow that the month-old tutorial used Tupress version 2.3.2, Bistup version 1.2.1, Claster version 3.7.2, and Pirend version 4.2.1.

Roger, on the other hand, had installed the latest versions of each, and they no longer played nice together. Also, Tupress 5 just came out and was completely different than Tupress 1 (there was no Tupress 2, 3 or 4).


Relates quite well to this tweet that’s making rounds:

Every JavaScript framework tutorial written more than 5 minutes ago →

Why a software patch is called a patch

Software Bugs

A common misconception is that a software bug is called a bug because of an actual bug that was once found.

The story goes that Grace Hopper found a moth stuck in Harvard University’s Mark II calculator in 1947 and that she taped it inside a logbook with the words “First actual case of bug being found”.

In reality Grace herself didn’t find the bug – somebody else from the team did – nor did they coin the term bug because of that event.

American engineers have been calling small flaws in machines “bugs” for over a century. Thomas Edison talked about bugs in electrical circuits in the 1870s. When the first computers were built during the early 1940s, people working on them found bugs in both the hardware of the machines and in the programs that ran them.

💁‍♂️ FYI: The logbook has been preserved and is now part of the collection at the Smithsonian (but not on display at the time of writing).

Software Patches

What seems to be legit however is the history of the term software patch. Back in the day when punched card coding was all the rage (although …), one actually had to put a patch of tape/cardboard over a wrongly punched hole in order to fix a bug.

Wikipedia tends to agree with this, even stating that whole sections would be replaced when needed:

Historically, software suppliers distributed patches on paper tape or on punched cards, expecting the recipient to cut out the indicated part of the original tape (or deck), and patch in (hence the name) the replacement segment.



Mailtrap.io – Fake SMTP testing server

var transport = nodemailer.createTransport({
  host: 'mailtrap.io',
  port: 2525,
  auth: {
    user: 'your-mailtrap-inbox-username',
    pass: 'your-mailtrap-inbox-pass'

transport.sendMail({ … });

Mailtrap is a fake SMTP server for development teams to test, view and share emails sent from the development and staging environments without spamming real customers.

Now this is great for testing: use mailtrap’s SMTP server and all mail sent through it will not actually be sent to the end-user but get caught in one inbox you can view. That way you can safely use real e-mail addresses in developmment environments.

Mailtrap.io – Fake SMTP testing server →

Hype Driven Development


Software development teams often make decisions about software architecture or technological stack based on inaccurate opinions, social media, and in general on what is considered to be “hot”, rather than solid research and any serious consideration of expected impact on their projects. I call this trend Hype Driven Development, perceive it harmful and advocate for a more professional approach I call “Solid Software Engineering”. Learn more about how it works and find out what you can do instead.

Some great examples (and conclusions!) on Microservices and NoSQL I must say.

Hype Driven Development →

Does code need to be perfect?

Andreas Creten, founder of Made With Love, on different needs in code quality depending on what type of product (POC, MVP, …) you are making.

Until your MVP really gets traction you can run on shitty code or even do things manually to prove you have a product/market fit. Only once you nail it and the customers start flowing in, you should start caring about code, but up until then, you’re almost writing one-off code too.

I especially like this part too:

Every week I talk with people with great ideas, but a tiny budget to execute them. When they ask me what it would cost to build their idea, I answer between 10k and a couple of billion, basically bouncing the question back and asking what they want to spend on it.

To me this quote relates to this chart on value over time:


One can spend a truckload of cash on a certain idea or feature, but let’s face it: the actual value is added in the first few iterations. There’s this point in time where it longer pays off to extensively put work into something. The end result might not be as polished, but it gets things done.

Does code need to be perfect? →

Sufficient Design

When I consider the quality of software design on the products we write and sell, I do so from the dual perspective of business owner and programmer.

As a business owner, I pay attention to our user’s success and our revenue.

As a programmer, I pay attention to our software process and code quality.

Balancing these perspectives is a practice I call Sufficient Design.

Sufficient Design →