“Not invented here” syndrome is not unique to the IT world.
When I first read the claim that HealthCare.gov, the Web site initiated by the Affordable Care Act, had cost $500 million to create,4I didn’t believe the number. There is no way to make a Web site cost that much. But the actual number seems not to be an order-of-magnitude lower, and as I understand the reports, the Web site doesn’t have much to show for the high cost in term of performance, features, or quality in general. This is hardly a unique experience in the IT world. In fact, it seems more the rule than the exception.
> Center Wheel for Success
Cryptography as privacy works only if both ends work at it in good faith
The recent exposure of the dragnet-style surveillance of Internet traffic has provoked a number of responses that are variations of the general formula, “More encryption is the solution.” This is not the case. In fact, more encryption will probably only make the privacy crisis worse than it already is.
> More Encryption Is Not the Solution
Quality happens only when someone is responsible for it.
Thirteen years ago, Eric Raymond’s book The Cathedral and the Bazaar (O’Reilly Media, 2001) redefined our vocabulary and all but promised an end to the waterfall model and big software companies, thanks to the new grass-roots open source software development movement. I found the book thought provoking, but it did not convince me. On the other hand, being deeply involved in open source, I couldn’t help but think that it would be nice if he was right.
Open vs. Closed: Which Source is More Secure?
The Hyperdimensional Tar Pit
If it does not take a full second to calculate the password hash, it is too weak.
6.5 million unsalted SHA1 hashed LinkedIn passwords have appeared in the criminal underground. There are two words in that sentence that should cause LinkedIn no end of concern: “unsalted” and “SHA1.”
Until our programming languages catch up, code will be full of horrors
Only lately—and after a long wait—have a lot of smart people found audiences for making sound points about what and how we code. Various colleagues have been beating drums and heads together for ages trying to make certain that wise insights about programming stick to neurons. Articles on coding style in this and other publications have provided further examples of such advocacy.
Related: Reveling in Constraints - Sir, Please Step Away from the ASR-33! - Coding Smart: People vs. Tools
Make a guess, double the number, and then move to the next larger unit of time.
When I started in computing more than a quarter of a century ago, a kind elder colleague gave me a rule of thumb for estimating when I would have finished a task properly: make a guess, double the number, and then move to the next larger unit of time.
This rule scales tasks in a very interesting way: a one-minute task explodes by a factor of 120 to take two hours. A one-hour job explodes by “only” a factor 48 to take two days, while a one-day job grows by a factor of 14 to take two weeks.
The sweet spot is a one-week task, which becomes only eight times longer, but then it gets worse again: a one-month job takes 24 times longer when it is finished two years from now…