NwAvGuy is the truly interesting story, NwAvGuy was some anonymous person who went to audio forums and warred on Schiit pointing out technical problems with their products and the way they do their marketing. I guess someone said if he knew so much about audio why didn't he go out and design and build his own stuff and so he did exactly that designing a headphone amp that has "legendary" status, and then he disappeared... His headphone amp: http://nwavguy.blogspot.com.br/2011/07/o2-headphone-amp.html

Some previous discussion about NwAvGuy on hacker news:

https://news.ycombinator.com/item?id=7451062

As an accountant turned programmer, I've noticed that my fellow software developers are terrible at understanding double-entry accounting and even worse at developing systems for accounting. This article uses a lot of words to not really say or explain much, if your aim is to know more about accounting look elsewhere, this article though factually correct confuses more than it informs.

As an example one thing he did specifically is to fixate on balance. Double entry accounting does is indeed a system for tracking balances of accounts but that's not all it does and it might be said that balances are a by product of what it really does. Double entry accounting tracks the flow of how money _moves_ through a system. Using double entry accounting you can get track the balances of accounts at a certain date _OR_ you can track the movement of money through accounts over a certain time period which we call an income statement. I've noticed that developers seem to fixate over the former without understanding that the latter is just as important. In other words it's not just important about how much money you have in an account but also how did the money get there?

I started a (now dying of bitrot for a couple years) accounting system in C++ that let you see your balance at every point in time.

All transactions were recorded as individual entries and every single one of them had to match for it to be processed.

So for a specific point in time, it was easy to simply re-run the transactions from last start to that point.

Some years ago I would have really appreciated the help of someone with your knowledge.

Right now I'm focusing on a videogame.

The blog entry is clearly not an accounting tutorial, but a historical overview of a process that led to current conventions.

Heh, in 2005 I was in the audience at PUC - Porto Alegre at FISL and watched it live.. =)

I asked DHH, "So where's the Brazilian Ruby community?" and he kinda mentioned it didn't exist yet. FISL back then was mostly python and java. Damn, it's almost 10 years since I moved to Brazil...

The article title is misleading. Application monitoring is not a unit test replacement. You want both.

I agree.