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.
Ruby==Love.
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
anew.
This reminds me of the
ClearRX
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:
What’s missing?
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,
notably
OmniGraffle and
Delicious Library , and has a
well-read blog. In a post
here
he asserts that “Unit testing is teh suck”.
Although Wil is a bright
guy and
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
bugs.
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
you make.
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
rationale:
- 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
caught earlier.
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
Continuous Integration.
- 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.
Steve Krug’s classic book Don’t Make Me Think
has been released in a second edition. This book helped me understand
web design and usability better than any other.
via
Jason Fried’s talk from O’Reilly’s Emerging Technology Conference is up on IT Converstaions I’m
only about halfway through, but it’s great so far. I’ve not seen Jason
speak in person(Jason & Co, PLEASE schedule another Building of Basecamp
in Chicago!), but I’ve heard several talks of his online, and they’ve
all been great. This is no different.
5 years ago, I went from being a “doer” (ie, a programmer), to being a
manager. This was not an easy transition. I suspect some people find
this transition easier than others, but I think most everyone who makes
the leap struggles in some way. If you’ve recently (or maybe not so
recently) made this move, you may find an
article
by Dave Gray helpful. It’s entitled “The craftsman-to-manager paradox”.
Dave defines the paradox as this:
As you move into management, the very things that made you effective as
a craftsman are now deadly threats to your success as a manager. Your
independence and self-reliance, which was an asset, is now a liability.
This is 100% correct, and I’ve seen it happen more than once; both to
myself, and to the others around me who were promoted from the rank and
file.
The article also includes a list he calls Ten Communication
Commandments for Managers.
Number 8 is one of the things I struggled with the most:
Don’t avoid difficult conversations. As a manager it’s your job to
initiate them when necessary.
I have often put off having those conversations, naively hoping that the
issue would resolve itself. It never did, and putting it off only made
things worse.
The other 9 items are equally valuable to anyone in a leadership
position.
Another point to be made though, which Dave neglects to mention, is that
great doers aren’t always great managers. It’s two completely different
skillsets. I’ve more than once seen someone who was a really great
developer/server administrator/router jockey get promoted into a
supervisory position and then fail miserably. This isn’t a reflection on
the individual, it’s more the fault of the person who promoted them. It
isn’t that leadership and management skills can’t be learned, it’s just
that some people just don’t have the aptitude (or often the desire) to
do the job well.
KEXP is an amazing radio station out of Seattle,
that simulcasts online. They don’t play much in the way of mainstream
stuff, but if your tastes run more towards the eclectic/alternative,
you’ll enjoy it. They also have an impressive collection of live
performances, and now even
have a podcast that highlights
artists you may not have heard of.
Check it out, you won’t regret it.
After my last Firefox
post,
I found an application that
alleges to tune Firefox automatically. It’s free, but appears to be
Windows only.
via
In this post
Robert asserts (as he has before), that “the thick client is coming
back”. I’ll agree that some apps are best as desktop applications, but
that list is dwindling quickly. Maybe you haven’t seen
this, or
this
Robert, you’re starting to sound a little like these
guys.