
Pinboard Creator Maciej Ceglowski Talks About Why Boring Architecture is Good - tortilla
http://www.readwriteweb.com/hack/2011/02/pinboard-creator-maciej-ceglow.php
======
neeleshs
_One interesting quirk of Pinboard is a complete absence of unit tests. I used
to be a die-hard believer in testing, but in Pinboard tried a different
approach, as an experiment. Instead of writng tests I try to be extremely
careful in coding, and keep the code size small so I continue to understand
it._

 _I've found my defect rate to be pretty comparable to earlier projects that
included extensive test suites and fixtures, but I am much more productive on
Pinboard_

Its great that this approach is working for him, but this may not work in a
decent sized project with multiple people working on it. I prefer a safety net
of test cases in such cases.

EDIT : Formatting

~~~
SoftwareMaven
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 :).

~~~
arethuza
On point 2 - I tend to find that if I write unit tests at the same time as I
write code then the code is structured to be easier to unit test. Writing unit
tests for code that has been developed without any concerns for unit testing
can be a complete nightmare.

~~~
Erikagd77
It is true that unit testing code that was not designed for testing can be
difficult, but it is certainly possible. Java reflection can set data values
in private fields for times when the original class did not include a setter
method for testing. Commerical solutions, like <http://tinyurl.com/4rabnef>,
provide stubbing frameworks to replace method calls at runtime and inject test
data without rewriting the original code.

------
szopa
It's funny how now most people seem to know Maciej Cegłowski as "the creator
of Pinboard." His blog, Idle Words [1] is one of the best I know of. I would
even say that the piece about Scott and scurvy [2] was _the_ most interesting
thing I read on the Internet in the last few years.

So, I am very happy about Pinboard.in being successful, but I think it's a bit
of a shame that such frivolous endeavors take Maciej's time from writing his
blog :P

(A bit more seriously, it's really nice to find a compatriot doing something
cool in more than one domain.)

[1] <http://www.idlewords.com/>

[2] <http://www.idlewords.com/2010/03/scott_and_scurvy.htm>

------
gfodor
Anyone who writes an article like this should be required to disclose up front
the current scale of the project they are talking about. (Users, data, number
of developers, etc.)

In his case, it sounds like a fairly small website developed by just himself.
Sorry if I'm not going to take this advice too seriously until this is
disproven.

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

~~~
naner
Is this thing profitable? It appears you've only got the one-time fee.

~~~
idlewords
Yes, it's profitable. Recurring revenue comes from the archiving feature,
which costs $25/year. The signup fee is mostly there to serve as a brake on
growth.

~~~
buro9
I would love it if you added something between full archiving and the basic
account.

I want the freetext search, but don't need to be able to access the archived
page (except for the equivalent of Google's text cache if the remote page is
down).

So yes I want archiving, but I don't need asset archiving for things like the
images, css, javascript on the pages. And yes I realise for a lot of hashbang
sites this would break, but that's just dandy with me.

I could sign up to the archiving, but with over 1,700 bookmarks I hesitate...
will it go and download all of them? I think that's creating a burden on your
service so I am not upgrading. I'd even pay the same price, or damn near it,
as the full archiving, but I really want to get the fulltext search in a
guilt-free way.

~~~
idlewords
If you upgrade, we do go fetch all the link content. We have users with 70k+
archived bookmarks, so you'd really be just a drop in the bucket.

It comes down to this - storage is cheap and development time is expensive. It
would take considerable work to retrofit the crawler to only fetch
dependencies for certain users, manage the case where they upgraded/downgraded
between levels, and so on.

~~~
buro9
Cool, that makes me feel guilt-free... one upgrade coming.

------
statictype
_Use frameworks for prototyping, but build from the ground up once you know
what you're building._

Isn't this contradictory to the idea of using boring well-tested
infrastructure?

~~~
cwp
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.

------
sfk
Excellent advice. Reminds me of Greenspun's tale of two servers:

[http://blogs.law.harvard.edu/philg/2009/05/18/ruby-on-
rails-...](http://blogs.law.harvard.edu/philg/2009/05/18/ruby-on-rails-and-
the-importance-of-being-stupid/)

------
rfugger
This is a good counterpoint to the steady stream of articles touting the
benefits of new technologies developed to serve massive-scale sites spanning
thousands of servers. Very few startups will ever need to deal with that kind
of scale, although it is nice to imagine having those kind of problems.

------
megrimlock
_Use caching as a last resort, not as a fundamental design strategy_

 _Resist excessive abstraction_

 _Set performance targets for yourself_

Excellent points for making any software perform well. I am working on
performance in a non-web app that suffers greatly from over-abstraction, and
over-caching to hide the overhead. Since design is subjective, railing against
this got me nowhere -- but setting performance targets truly shifted the focus
of the team. Now instead of debating how many internal layers we need and how
to name them, we focus more on our runtime budget, and how to make the
hardware solve the problem in that time.

------
jasiek
Did you notice the price? It is based on the current number of users
(multiplied by 0.001). With the price rising like that is should be pretty
easy to figure out an upper limit of how much users would be willing to pay
for it.

------
gnubardt
Using a common design for architecture is kinda like using a well known design
pattern or framework. It allows a new developer to easily understand your
project.

------
mise
This is great for building your own app. For hosting a mildly popular phpBB
forum, though, I've been stuck with its built-in clumsiness and 1sec+ load
times.

------
rbranson
I/O isn't awful on virtualized infrastructure, I/O is awful on EC2.

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

