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.
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 :).
My unit tests are half for today—they actually let me code faster and better—and half for next month, when I discover a much better way to do things and reorganize my code savagely.
3 years from now? That's just a bonus which lets me feel smug. The real payoff was immediate, and did not involve any virtuous self-discipline.
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.
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.
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.
I've often found that dogma is useful for the beginner, because practice is needed. When you mindlessly apply something, you focus on the application, and not if it's appropriate.
Once you've got the application down fine, then you have some experience to base your decision on when is and is not a good time to actually apply things.
> 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.
Yes, this approach is ideal when you are one person working consistently on the same project, and have much of the design in your head, which is feasible when you keep the code size small.
It suffers when you have multiple people working simultaneously, or if you have to take a break before returning to the project. In those case, a secondary automated statement of what the system should do is quite useful.
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.)
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.
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.
You're right - MongoDB did seduce me with big, bold promises and I even had it set up across some of my servers. Took me a whole lot of effort to get that far, then BAM, it all fell over and there I was like an idiot trying to get it back up when I could have been working on my startup instead.
The hard part of any new technology is bouncing back when things go wrong, and I don't have to do that now that a 3rd party does it for me, which brings me back around to Simple again.
There's a whole bunch of stuff I would like to learn but the reality is I can't have my startup falling over every time I fumble through learning something new, especially when what I already know can still solve problems.
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.
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.
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.
His website pricing gives a hint as to how much the app has made him:
> The [Pinboard] fee is based on the formula (number of users * $0.001), so the earlier you join, the less you pay.
The current price is $9.22, so following this formula he has ~9220 users, which has paid him roughly 42K. He also charges $25 (minus your sign up fee) for archiving, which would bump that number up a bit.
I hate to be That Guy but they have repeatedly said that's not the entire formula. The most recent figure I saw them share puts them at around 15k users.
Current debate aside, just like to say thanks for Pinboard from a happy customer. Good example of something that "just works", so you must be doing something right :-)
Well, I don't know if you intended this article to be posted on hacker news or not, but it certainly lacks any compelling data or facts to make a real argument for your claims.
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.
He says: "I think many developers (myself included) are easily seduced by new technology and are willing to burn a lot of time rigging it together just for the joy of tinkering. So nowadays we see a lot of fairly uninteresting web apps with very technically sweet implementations."
This is rather insulting to two groups of people: people that are working on things this author would not think are interesting, and people who are overcoming technical challenges by deciding to use new, less mature tools since things like the LAMP stack have well known limitations. (the overlap of these people, as you can probably guess, is pretty high.)
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.
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.
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.
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.
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.
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.
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.
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