Pinboard Creator Maciej Ceglowski Talks About Why Boring Architecture is Good

I think the size of a test suite should be dependent on the size of the project and team, as you stated. Most TDD advocates are overboard with it imo; a test case should certainly be written when a regression occurs to make sure it doesn't happen again, and tests should be filled in in other cases as time and circumstances permit (recognizing that tests are an important part of the application that you can't just shove off until your favorite theorized utopian corporate culture is realized), but I've never been a big fan of making the development process all about tests. I think it's overzealous and ultimately just burns people out on testing, causing them to get lazy and go almost test-less when they have the option. There are times when it's better to discard form and just write some code straight up without descending into a mire of testing beforehand.

The problem is that unit tests aren't for today. Unit tests are for 3 years from now when you've forgotten how a system behaves and you need to make a major change to it (nb: I'm not talking TDD here). When you get done with that change (and every company I've worked at with no unit tests has), you'll look back and realize you had three choices:

1. Write the unit tests while the code was fresh. Ideally, you wrote well designed unit tests so you didn't have to constantly deal with maintaining crappy test code. Unfortunately, most test code doesn't seem to be well-written, DRY code, so you spend a lot of time in the interum maintaining it.

2. Figure the code out again when you need to change it (likely somebody else is doing the figuring out by then) and write unit tests that show current behavior. The "figuring out" step is always nastier than you expect.

3. Start digging and hope you come out the other side with something reasonably similar to what you started with.

The trick is figuring out which one optimizes best for your business. Pinboard might be able to get away with #3. Air traffic control may have no choice but to be #2 (did people write unit tests way back then? I know I didn't write any unit tests on my Atari 600 in '83 :).

> Instead of writng tests I try to be extremely careful in coding, and keep the code size small so I continue to understand it.

Amen, brother. I feel exactly the same way. I find this approach works perfectly 99%+ of the time, and regardless, I end up spending way way less time writing and maintaining code because of it. Understand what you're doing, and why, and you reap benefits not just at the tactical momentary level, but long term and architecturally as well. Understand the codebase really well, and it's much easier to diagnose issues that happen in production or at a larger scale.

It is a fairly small website developed just by myself. I don't think I've ever characterized it otherwise.

I don't understand your criticism. All that the article says is that there are benefits to using well-understood technologies that have been around for a while and have proven to be fairly stable.

As someone who works (during the day) for a government agency with well over a million employees, this is something I understand well. Granted, we're not Twitter - but we do serve a silly amount of data using old-fashioned and "boring" technology, and we're glad that we use it because it's proven itself to be reliable.

I like everything he had to say in that article and share his beliefs. It's easy to lose yourself in the myriad of fancy new technologies and stuff where you go to extraordinary measures to hack together a solution.

Simple is good - it's mature, it's easy to understand, it's easy to optimize, and it works. And you don't need to spend a bunch of time and make a bunch of mistakes learning it.

Scale: 120+ million people a month.

Stack: IIS + SQL Server + MongoDB, glued together almost exclusively with C#. The only part of my stack that's remotely cool is MongoDB, and I only use it on a little bit of my platform and I outsource it to MongoHQ.

Nah, given that he's using PHP it makes sense. Your basic PHP installation supplies so much bullet-proof infrastructure right out of the box, that a framework on top of that provides more uncertainty than functionality.

It reduces complexity and uncertainty.

At the company I work for we have 2 internal APIs being worked on:

1) A freebase/metaweb style API backed onto a relational database

2) A traditional set of web services backed onto a document based database

The former gives us the ability to invent the questions we want to answer and validate whether those are valuable questions. But it carries the risk of complexity and the problems of scaling in return.

The latter gives incredible performance once you know what questions you want to answer. But it is much harder to prototype things on as that's a bullet-proof big industrial thing and things move slowly in there.

We basically recognise a difference in the balancing of pros and cons between the systems that help you prototype fast and the systems that help you scale dramatically and securely and that have to be maintained. And it sounds like this is the underlying point about using a framework for prototyping and then building your own simple, pared down specific thing.

Try using a Xen instance when a RAID drive has to be rebuilt. I did!