I have a book I published using Leanpub and I set the minimum to be $10. Some people pay the minimum. Some people pay the suggested price of $15. Some have even been as generous as to pay MORE than the suggested price.
If I ever decide to give away my book for free for a limited time, I would not feel bad about people giving me $0 when they could give me whatever they want.
I am in agreement with Raganwald in that I just want people to read it and find it helpful.
I wrote a short Python tutorial (http://www.korokithakis.net/tutorials/python/) which I packaged up as a book in a few hours and put on LeanPub. I used to sell it for $2, but the LeanPub guys changed the pricing structure to minimum/recommended, so I set the recommended price at $5.
People have been buying it for $5 ever since, and I've even had some $8s and $10s. I even include a link to the tutorial right on the book page, because I don't think it's worth even $2, but apparently people do!
I suggest you do some research about the author of the MicroPHP manifesto before throwing snark out there like that.
Ed is a personal friend (and we do a podcast together) with many, MANY years of experience building applications using PHP. While I don't agree with him on some points in there, he does deserve to not be shit on by people who can't be bothered to do 30 seconds of research about the author.
I didn't do any research about the author and just now found out his name is Ed. I mention this because I'm someone whose only experience with this author was that one post and even with that small amount of information I was able to infer that the guy had experience and knew what he was talking about. I also think its very obvious that what Ed suggests is not to be taken at face value. When I read the microPHP Manifesto my reaction was that it made total sense but of course, as always, follow it if and when it makes sense. Taking into account that the post was probably a kind of rant as a reaction to some framework frustrations his manifesto makes perfect sense.
Now the author of this article refuting the Manifesto seems to be under the impression that what Ed suggests should be the way things are done from now on. It's clear as day that all Ed was sayng was that sometimes the MicroPHP Manifesto tenets make more sense. And they do! Sometimes!
Guess what? Everyone is right! Hopefully that doesn't make some people's brain explode but both authors are correct. Mileage varies. The thing I didn't like most about this was how he picked apart the drummer analogy. I felt like it was a low blow and not really necessary.
My experience is that it is a very rare and enlightened management team that allows developers to go back and clean up the technical debt that was created during the mad dash to get your application out the door.
Most of the time you are stuck with technical debt because there is no room in your timeline to go back and fix stuff that you know is broken.
YMMV, but as the blog post author I'm keenly aware of this situation.
With the understanding that I do most of my work in the most-bullied, down-trodden programming language here on Hacker News (PHP) I think that your choice of language, framework and persistence layer leads to technical debt or friction as raganwald commented above.
Like I said before, I view infrastructure debt as the cost of consistency in your environments and the cost of moving your code from one environment to another. Very rarely is the choice of language going to be a problem, unless you are trying to use a language in a way it's not intended to be uses (to throw out a completely random idea, like trying to use PHP as a functional language ).
Frameworks are a sore point for people, but mainly because they choose to fight them instead of trying to do everything the framework's way. Picking the wrong framework is a technical debt situation, not a problem of moving code from dev to production.
Persistence layer stuff is also a technical debt / friction issue. Chances are that you could use that particular data store without the persistence layer you chose. For example, I struggled to learn Doctrine1/2 but once I learned how DQL worked it became a lot easier to break out of the object-only contraints and create custom queries.
Upon reflection your use of the term "friction" is a good one. Although I tend to look at "debt" as something you pay back as quickly as possible but sometimes you can only pay it back in installments.
I guess you could say having too much infrastructure friction eventually leads to one humungous infrastructure bonfire. :)
Well, “friction” is on ongoing cost but doesn’t result in some catastrophic event down the road, whereas debt may or may not have an ongoing cost but carries with it some non-trivial probability of disaster. Like real debt, the longer you wait to eliminate it, the more expensive it is to fix and the worse the catastrophe if you on’t fix it.
So... I tend to think of source control problems as being infrastructure debt, because you are definitely going to crash and burn eventually, and the longer you wait, the worse the problem will be. I am open to rethinking this, but I would classify automated deployment as being friction. If you can deploy by hand, and everybody knows how to deploy by hand... It seems that deploying by hand is probably friction while you are in development and then debt once the product is in “actual” production with end users. In development, you might make a mistake, forget a library, and fixing it is work but not catastrophic. But once you have actual users, making a deployment mistake could produce irrevocable disaster.
Anyways, just to be clear, I’m only bringing up the distinction for the sake of discussion. I like the post just the way it is.
Keep in mind, though, that even "friction" will eventually cause a team's productivity to drop down to 0. The amount of friction that a given team can tolerate depends on the team members, of course, but especially on the size of the team (see: Mythical Man Month).
There comes a point that even a tiny bit of friction, spread out over enough developers, eventually causes the marginal productivity boost of adding new devs to reach 0. That can happen even without friction, but the friction exacerbates the trend.
I would place database design debt firmly in the technical debt side of the ledger (as it were). To me, infrastructure debt deals more with consistency across environments and consistency in moving code from one environment to another.
I also agree with you that database design debt is very expensive and, as you pointed out, leads to paralysis over fixing problems with an established application.
I was nitpicking, but it got me wondering about the history of revision control systems as I was pretty sure I had used RCS in the 1980s and I had to check to see if my memory was playing up. :-)
I'm a long-time PHP user (since 1998) but I never really peered inside the discussions of the internals of PHP. Now that I'm more connected to others in the PHP world, what you see inside the mailing list for PHP internals is what I would label as obstructionism and an attitude that seems to imply that if you cannot code the requested changes yourself, don't even bother asking.
Lead, follow, or get out of the way are the only three choices available to any language.
Also, if you can code the change yourself it gets rejected as "not a bug" for a few times, then they think about it and say that it's too late for any reasonable release and that it will go into PHP 6 or 5.3 or something that you won't upgrade too because it breaks too much other stuff.
> attitude that seems to imply that if you cannot code the requested changes yourself, don't even bother asking.
I think that's fair actually. The internals list is not for wish-lists; if it was it would be flooded and no useful work could be done there. The problem is that there are coded patches for some of these features (like short array syntax) but they're still not being included.
It's not productive and everyone loses with that attitude, because "... don't even bother asking" essentially blames others for not implementing ideas stuck in your head.
