Steve Pavlina has updated one of his
older articles into a new one titled Do it
Now, in which he
describes the method he used to graduate college in three semesters
with a 3.9 GPA. From the article:
In order to accomplish this goal, I determined I’d have to take 30-40
units per semester, when the average student took 12-15 units. It became
immediately obvious that I’d have to manage my time extremely well if I
wanted to pull this off.
That’s an understatement. I’m not sure that just anyone could pull this
off, but Steve claims he did (and I really don’t have any way of proving
one way or the other).
Regardless, there are some really good time principles in this article.
Definitely worth a read.
Via Martin Fowler, I
learned that John Vlissides
died after a long battle with cancer. John was one of the Gang of
Four who wrote the definitive book on design
His page on c2 has been
turned into a sort of memorial wiki page by the people who had met him.
Aside from the book, he has had a significant impact on a number of
people. I do wish I had gotten to meet him.
Over at the Creating Passionate
(which has more useful information on it than any other blog I can think
of), there’s an excellent post called If your software was on a
which lays some ground rules for your applications:
How would your software (or product, service, book, cause, etc.) behave
on a date? Perhaps the best model for software developers is the singles
scene, so let’s see how this time-tested dating advice for men might be
applied to software:
The article goes on to give some excellent advice, including “Be
polite, be helpful”, and “Be forgiving”.
It’s an excellent article overall, but I couldn’t help but think there
was one thing missing: “Be easy to get to know”. Offer a free trial.
Show me a flash or Quicktime demo of what you can do (screenshots are a
copout - how many people started using Rails because of the 15 minute
video? I did.), and offer a forum for sharing information with other
users, and with the software’s developers.
37Signals gets this last point very well,
their product blogs are very useful.
Ship It! By Jared Richardson and William Gwaltney Jr.
Ship It! is a book about basics. It’s an education in the fundamental practices that are needed to develop software successfully. This is the stuff they don’t teach you in college. Ship It
doesn’t espouse a particular methodology (such as Scrum or XP). Rather,
it is a set of practices. The advantage of this is that you don’t have
to adopt everything in an all-or-nothing fashin. In fact the authors
state explicitly that you should use the things that work and don’t use
the things that don’t work. This will work particularly well in
situations where someone works in an environment that has an entrenched
methodology. While management might not be willing to buy off on a
wholesale switch to a different methodology, many of the practices
outlined in this book don’t require you to spend any money. Therefore,
individual developers, leads, or managers can implement a couple of
practices (say “The List”, and daily meetings) without needing
Let me start off by saying that I’m a huge fan of the Pragmatic
Programmers. The original book
completely changed the way I approached programming. I’ve bought several
books from them since then, and have been extremely happy with them all.
This is rare. Even O’Reilly has a few stinkers amongst all of their
great books. The point is, I started reading this book with high
The book is divided into four basic sections:
- Tools and Infrastructure
- Pragmatic Project Techniques
- Tracer Bullet Development
- Common Problems and How to Solve Them
The first section, Tools and Infrastructure, covers the basics of
software development tools. It not only covers what you need, but how
you should use it. The tools covered here include source control (with
an emphasis on Subversion), build scripts (using tools like Ant and
NAnt), continuous integration, defect and feature tracking, and more.
The book obviously can’t go into each tool in great depth, but there is
enough there for you to get a good understanding of why you would want
to use these tools.
The section on Pragmatic Project Techniques is equally interesting.
As I said before, Jared and William don’t advocate any particular
methodology, but have acquired a collection of practices over their
years of software development that work. That said, there’s a fair
amount of overlap with traditional agile methods. It covers techniques
such as daily meetings (aka Daily Standups in XP), a shared list of work
referred to as “The List”, among others. I would imagine that this
section of the book would be the most useful to the majority of people
reading this book. Geeks tend to focus on tools (section 1), but often
ignore the processes that make a project successfull (or not).
Tracer Bullet Development was covered in the original Pragmatic
book, though this book covers it in much greater depth. It’s very useful
in situations where the client doesn’t fully know what he/she wants. You
essentially build a prototype, and use it to draw out the requirements
from your customer. It’s more involved than that (it warranted its own
section in the book), you’ll need to read the book to gain a full
Common Problems and How to Solve Them was probably my favorite
section of the book. It’s a collection of 18 recipes for how to handle a
given situation using the principles outlined previously in the book. It
covers situations like “The customers are unhappy” and “Features keep
creeping in” with practical advice for how to deal with them. All of us
find ourselves in these kind of situations from time to time, and this
book would come in very handy when they do arise.
In summary, I think this is an excellent book. It’s not billed as such,
but it could almost be considered a sequel to the original Pragmatic
book. While the original focused on the tools and techniques of the
trade, this book elaborates on those and adds a lot of information on
processes. Combine this with the “Common Problems” section, and you have
a very useful book indeed. The writing style is somewhat casual, similar
to the other books from the Pragmatic Programmers, and the book is
filled with real-world examples from the authors. I would highly
to anyone interested in improving their software development skills.
A collection of tools that support PostgreSQL, courtesy of a commenter
Slashdot post (both commercial and non represented here).
pgAdminIII Side note on this one - there’s a
beta of the new version out, the UI is quite improved.
ERWIN data modeller
CASE Studio 2
Creating a header background Good
information for the design challenged (like me).
Tag database schemas
A good look at a variety of database schemas for “taggable” information.
Creating a business logo
Ian Landsman walks through the process of creating a logo for your
Creating printable documents with Ruby Discussion
of PDF::Writer, both standalone, and with Rails.
One of the things that I love about Ruby is that it’s intuitive. If I
don’t know the syntax for a particular thing, I can often just guess.
More often than not, I’m right (or real close). That’s the mark of a
great language. It behaves like you would expect it to behave.
There’s an interview in the latest Make
magazine with Dean Kamen, inventor of the
Segway and many other cool things. It’s a good interview, and definitely
worth your time to read it. One thing that stuck out was this quote on
designing things: “I do very little research as to what the product
should be … if you do “product research”, the product that you end up
with will be similar to what already exists”.
I think this is why we see so many products that only get evolutionary
upgrades, instead of revolutionary ones. People are stuck on what
already exists, instead of being willing to throw it all out and start
This reminds me of the
medicine bottle redesign. Pill bottles have looked basically the same
for as long as I can remember. Now someone has come along and turned it
on it’s ear. None of the changes required new technology to be invented,
it just needed someone to think about the problem differently.
Ruby on Rails is much the same. Everything
in there had been done before, but
someone came along and said “let’s look
at this problem differently.” And it’s turned the web development world
on it’s ear. Even if Rails were gone tomorrow, it’s impact would live on
for years to come.
What else is due for an overhaul?
Here’s my short list, off the top of my head:
As I meander through the internet, I often find sites that inspire the
wannabe designer in me. I’ve started collecting them, so that when it
comes time to develop applications, I have a collection to go to for
inspiration. In the event that I’m working with a designer, it gives me
something to send them and say “I like stuff like this”.
Here are a few recent favorites:
Where do you find inspiration for your work?
Wil Shipley is the author of several well known Mac applications,
Delicious Library , and has a
well-read blog. In a post
he asserts that “Unit testing is teh suck”.
Although Wil is a bright
very likely a better programmer than I will ever be, this is completely
out of touch with reality. I suspect anyone that has done
TDD, or even
used a unit testing tool would agree with me.
Wil starts off with this statement:
I've NEVER, EVER seen a structured test program that (a) didn't take
like 100 man-hours of setup time, (b) didn't suck down a ton of
engineering resources, and © actually found any particularly relevant
Well, I think Wil may be exaggerating a bit with the 100 hours nonsense,
but let’s assume he’s not for just a second. I’ve never written a single
line of ObjectiveC code, but if
OCUnit is anything
like the other unit testing tools out there (NUnit, JUnit, Test::Unit),
this is a ridiculous statement. As for not finding relevant bugs, I find
it unlikely as well.
Next up is this statement:
It's actually provably impossible to test your program with every
conceivable type of input programmatically, but if you test by hand you
can change the input in ways that you, the programmer, know might be
prone to error. Sorry, wrong answer. Anything you can do
manually can (and should) be automated. Two reasons:
- Manual tests aren't reproducible. Duh.
- Manual tests take a **lot** of time to do. Because they're manual.
Double-duh. Furthermore, things that are time consuming are often
skipped when people get tired, lazy, or just need to get the thing
out the door. And unless you wrote down all of those manual tests,
if the person who wrote the code (and was doing the testing) leaves
the company, you're in trouble.
Summary: **Unless you have a good set of unit tests, real regression
testing is nearly impossible.**
Next, Wil describes his testing methodology:
When you modify your program, test it yourself. Your goal should be to
break it, NOT to verify your code. That is, you should turn your huge
intellect to "if I hated this code, how could I break it" as SOON as you
get a working build, and you should document all the ways you break it.
\[Sure, maybe you don't want to bother fixing the bug where if you enter
20,000 lines of text into the "item description" your program gets slow.
But you should test it, document that there is a problem, and then move
on.\] You KNOW that if you hated someone and it was your job to break
their program, you could find some way to do it. Do it to every change
There amount of time it would take to do this on a program of any size
is ridiculous. Although Wil may have the self-discipline to do this, the
rest of us likely don’t. And again, it’s not a repeatable process.
Here’s the bottom line: Unit tests are important. Extremely important.
And they don’t add time to a project, in fact in most cases they will
reduce it. At first blush this doesn’t make much sense, but here’s the
- You typically write this code anyway, but end up throwing it away.
How often have you written some chunk of code, then written a piece
of throwaway code to test it. Unit tests are all about taking that
code and making it automatic.
- You’re trading test-coding time for testing and debugging time. Yes,
it takes time to write unit tests. But it also takes a lot of time
(arguably more) to run a bunch of manual tests. It also takes time
to debug problems found later on that could have been
Wil has forgotten one of the basic rules of software development: Catch
Bugs Early. If you catch a bug when you’re just getting started, it
costs nearly nothing to fix. Find that same bug after you have released
it to the world, and it costs significantly more - particularly if
you’re not talking about a web application.
On top of all of this, there are a couple of other points worth making
about Unit Tests:
- Refactoring, or any type of major code change, is scary without good
unit tests. Often, people avoid changing the code altogether and
just live with it’s warts. I can’t find the post now, but one of the
37Signals guys blogged about how having
unit tests made the architectural changes that were made to Basecamp
a lot easier.
- When you have to integrate with other developers, unit tests
are invaluable. This is particularly true when coupled with
- Unit tests (if done right) will improve the architecture of
your code. You simply can’t have a highly-coupled application if you
are unit testing everything independently.
- Unit tests serve as documentation for how the code
actually works. Forget that dusty API reference that hasn’t
been updated for three versions. A set of passing unit tests tells
you what the code does right now. Paired with a code coverage tool,
it can even tell you what’s not documented.
Summary: Unit tests == Awesome, and represent all that is good in the
world. I certainly don’t think that they’re a panacea, but they’re
certainly not “teh suck”.
I didn’t expect this to turn into such a rant, but when people who are
respected and admired in the community make harmful and incorrect
statements, they need to be corrected.