Month: <span>March 2013</span>

A few weeks ago, “Uncle Bob” Martin put up a great post on the 8th Light blog, about the value of disciplined software development being just as important, if not more important, for start-ups as for established companies. – The Start-Up Trap:

“As time passes your estimates will grow. You’ll find it harder and harder to add new features. You will find more and more bugs accumulating. You’ll start to parse the bugs into critical and acceptable (as if any bug is acceptable!) You’ll create modules that are so fragile you won’t trust yourself, or anyone else, to modify them; so you’ll work around them. You’ll build a festering pile of code that, with every passing week, requires more and more effort just to keep running. Forward progress will slow and falter. It may even reverse as each release becomes buggier and buggier, and less and less stable. Catastrophes will become more and more common as errors, that should never have happened, create corruptions and damage that take huge traunches of time to repair…

“… If you want to go fast. If you want the best chance of making all your deadlines. If you want the best chance of success. Then I can give you no better advice than this: Follow your disciplines! Write your tests. Refactor your code. Keep things simple and clean. Do Not Rush! You hold the life-blood of your start-up in your hands. Don’t be careless with it!

If you’re an indie developer, working on a startup, or come to think of it if you’re doing any software engineering at all, go read it.

And while you’re at it, have a listen to David Smith’s interview with Brent on Developing Perspective, where he talks about technical debt in NetNewsWire as the iPhone and iPad versions’ deadlines loomed. (Bonus: Identical Cousins innagural episode, Software Is Hard.)


Some of Apple’s classes like to throw exceptions, log a message to the console, and then crash your app, taking your stack trace with it.

Needless to say, this makes debugging extremely difficult, since you can’t inspect memory or even see who called what to cause the crash.

Thankfully, you can fix this! Here’s how:

  • Open the Breakpoint Inspector (Cmd-6).
  • Click the little + button in the lower-left corner.
  • Choose Add Exception Breakpoint…
  • Leave the defaults alone, and click Done.

Now whenever your app causes an exception, you’re dropped into the debugger, with a full trace, and access to all of your in-memory objects. Yay!

Thanks to Sean on Stack Overflow – though I also heard this in class once or twice and failed to implement it. (Whoops!)


Marco Arment has a great post on the meta-issue surrounding Google Reader’s shutdown, on the issues around “free” in the tech industry:

“If you try to play by the traditional rules and regulations, you run the risk of getting steamrolled by someone who’s perfectly willing to ignore them. Usually, that’s the biggest potential failure of the tech world’s crazy economy, which sucks for you but doesn’t matter much to everyone else. But sometimes, just like unregulated capitalism, it fails in ways that suck for everyone.”

Go read it.