Look. This SOPA/PIPA thing.
Copyright infringement is already illegal (criminally) and actionable (civilly). SOPA/PIPA is just an attempt by the big media companies to offload their enforcement costs on you and me. Rather than doing their own damn work chasing down copyright violators, they want to keep everyone off sites that *might* be used for unauthorized copying.
SOPA/PIPA is kind of like making it illegal to buy blank T-shirts because you might put someone else’s trademarked or copyrighted image on them. Which is awesome if you’re the one with a “famous” image or brand, but sucks if you just want to publicize your mom-and-pop business or your kid’s band.
So since when is it your job and my job to make sure Disney and Comcast’s copyrights can’t possibly be infringed upon? Why the hell isn’t it their job?
The inevitable war story, because I do that:
I used to do programming work for an industrial/grunge record label. (Brush with fame: I knew Marilyn Manson’s accountant.) They actually had lawyers dedicated to suing bootleg T-shirt vendors at concert venues. It was an expensive pain in the ass, but they figured it was a cost of doing business and protecting the brand.
It wasn’t perfect, because you can’t catch and sue everyone, but it worked well enough and the label was quite profitable.
It’s not good enough for Disney though. They think their right to guaranteed profit trumps your right to run a web server. That’s the issue.
The Single Most Effective Optimization
A year and a half ago, this really interesting scientific programming project more or less dropped into my lap.
The original code was written by a physicist–let’s call him Jim–who wasn’t a professional programmer but actually did an okay job writing and maintaining this Visual Basic Classic (pre-.NET) code for several years. “As a programmer,” someone might say in a gently mocking tone, “Jim’s quite a good physicist.”
So it’s cool. The important thing was to solve the scientific problem, and that it did. When I picked up the code with a mandate to get it working on a .NET platform and add a few features, though, I found it fairly hard to follow. A lot of the operations really needed to be event-driven but simply weren’t. There were a lot of modal dialogs and there were Windows forms with a ton of overlapping controls that got shown and hidden at various steps in the process.
So it was slow going, getting the thing to build and actually run on .NET. But the thing that saved my sanity in so doing was asking one simple question over and over again:
Does this code get used at all?
In many cases, the most difficult code was unmaintainable because nobody had to maintain it anyway. I consulted with the client, was told that the code implemented a feature that nobody used or even knew about, and simply deleted it. (After! Of course! Having all the originals under version control!)
There was a mishap or two in that regard, such as code invoked by menu options that seemed to be permanently disabled, but still. I could go back to version control (Subversion in this case), pull the original code back into Visual Studio, and massage it to get it to work.
But the massive reduction in workload caused by not having to work on 30% of the system at all more than made up for the few little problems. I’m pretty sure that the most effective development optimization of all, when working on legacy code, is simply cutting out the code that is never invoked or nobody cares about.
Things learned while pairing
I spent a Sunday in January at Corey Haines’s Code Retreat, out on the LeanDog boat. Aside from being too darned early in the morning, and aside from the fact that I had to bail at the 3pm break because my kid thinks she needs a ride to college, it was a fantastic use of time.
The event is like this: You show up, hang out, grab a pair partner, and start doing test-driven development (TDD) on a specific programming problem. After forty-five minutes, you stop programming, join the big group again for a debriefing, and do it again from the beginning with a new pair partner.
And you do this like six times during the day. (I only stuck around for four iterations.)
The problem space
The actual programming problem was to mplement Conway’s Game of Life. It’s a devilishly clever assignment, partly because anyone who’s taken more than one Computer Science class thinks they’ve already solved it. But oh no.
If you don’t know about the Conway game, it’s not really a game you win or lose. You have an unlimited “board” of square cells arranged in rows and columns. Each cell is considered either “alive” or “dead.” On each “turn” every cell counts its eight immediate neighbors (including diagonals); if it has fewer than two live neighbors it “dies” of loneliness; if it has more than two live neighbors it “comes to life”; and if it has exactly two live neighbors it just stays the way it is. That is all. You just watch it go, turn after turn. It’s just cool. There is no object other than watching the patterns that “grow” from various starting configurations.
(If the above sounds like a really stupid waste of time, you are not a geek. Please find another career.)
Harder than it looks
This is actually kind of hard to implement in a real object-oriented way. How do you design your classes? Is there a Board that contains (“has-many”) an infinte number of Cell objects? That won’t work quite the way I made it sound, will it? How about keeping a collection (like a C# generic) of just the live Cells? (It’s a lot easier if you get to assume a limited playing field. But alas.)
What I learned
Somewhat importantly, Corey didn’t expect us to use any particular programming language. He encouraged us to pair with colleagues who were using languages we might not even know yet.
I learned a bit about object-oriented design, if by “learn” you mean “find things to argue with.” Briefly, master crafters like Corey seem to prefer a lot more abstraction in class design than I feel like wrapping my head around. I usually like a one-to-one relationship between code space and problem space; so to me an object is “a thing that does things,” and a class is the idea of what that object looks like and does. If I can’t think of it as a thing, it’s not an object– it’s a method. Maybe.
I didn’t get very far with my pair partners on any of the iterations. We kept getting hung up on the TDD cycle, confused with the problem space, or stuck on mundane tactical issues. In that way it was frustrating.
On the good side, I got to hang out and pair with Angela Harms on an iteration. There was a mutual aha moment when I said out loud, “A cell knows if it’s going to live or die.” Angela thought it was some Zen kind of cool. I thought I was having fun anthropomorphizing the code. We’re both right.
My man Chris Sanyk was there too. He wrote about it, and wrote about it again, and wrote about it yet one more time. Our favorite insight occurred when Corey said something about running unit tests only on public methods, which annoys me because sometimes all the interesting logic is in private methods. I was launching into a “rant” on this topic, according to Chris, when Chris simply said, “So write the test method inside your class.”
I was stunned for a moment, then opened my mouth to argue, realized what I was about to say would be wrong, then started to say something else that was wrong, and finally looked at Chris and went “aaaaaaah.”
Is that the right answer? Beats me. It’s not mainstream as far as I know. But it turned my idea of unit testing on its side.
Preparing for GiveCamp 2011
Hey, everyone… I’ve been out of the blogging space for a while for a lot of reasons. Some of it has to do with having too many projects going on at once, with competing deadlines. Some of it’s about being tired. Some is because the things I want to write simply aren’t ready to hatch yet. And a little of it comes from this project I’m not supposed to say a lot about.
But here’s something new! At the end of the day yesterday I spent some time in conference with the organizing team for this year’s Cleveland GiveCamp. We already have bunches of eager volunteers, a floating venue, some early sponsorship interest, and a decently clear idea of what’s going to happen next.
What you need to know
GiveCamp is a bunch of designers, admins, software developers, and business people who pitch in for a weekend to create websites and software applications for free for nonprofit organizations.
This year in Cleveland it’s the last weekend in July, starting the evening of Friday the 29th and rolling through the afternoon of the 31st.
We haven’t decided which agencies and organizations are going to get new websites and software applications this year, but we will probably start accepting applications around May 1st.
We are already taking volunteer commitments! If you can design web graphics, or can lead a project, or know something about content management systems (especially WordPress), or write software, or are good at organizing, or if you just want to help–please sign up now!
We are also working on a sponsor packet, for companies and individuals who might consider donating money, materials, food, T-shirts, or services. That should be available within a couple of weeks. GiveCamp runs cheaply, but we still need a lot of food, caffeine, and supplies to keep it going all weekend.
Last year
Cleveland GiveCamp was a huge hit. We used all of the LeanDog boat plus half of Burke Lakefront Airport (thanks everyone!), had about 110 volunteers who worked on 21 projects, and left charged up to do even more this year! I personally know three people who got hooked up with new jobs as a result of the connections they made at GiveCamp, and everyone had fun. Also, the food was far better than at most tech conferences.
So.
If you’re going to be anywhere near Cleveland at the end of July, here’s what you can do:
- Volunteer for the big GiveCamp weekend of July 29-31.
- Start planting some mental seeds for sponsorship at the places where you eat out, work, or shop.
- Talk to your friends and associates in nonprofit organizations–do their current websites suck? Are they looking for some kind of new software program that doesn’t already exist?
- Watch this space, and ClevelandGiveCamp.org, for more in coming months!
- Are you in for this year? Were you there last year? Drop a comment and tell us how it went.
I promise hard work, nice people, and lots of fun. See you in July!
What I like about Rails
Somebody asked a few months ago on LinkedIn, “What do you think about building a web application in Ruby on Rails?” Here’s my short answer:
Specifically, I love the way Rails lets you do database access. The simplest way to hit a database table with Rails is to run a generate scaffold command that creates the table for you and writes all the code for a super-basic CRUD (create, update, delete) web application. You can edit the generated “scaffold” to make it prettier or to add functionality.
When you go just a little farther, you find that the ActiveRecord class does most of the boring database work for you. Every table (“Model” in MVC parlance) is set up to inherit from ActiveRecord, and you don’t have to write out (in your code) what columns it contains because ActiveRecord figures it out for you at runtime.
Better still, you can add lines to your Model code such as :has_many x or :belongs_to y to indicate relationships (joins) with other tables. Again, Rails works out the details. You really don’t even have to know what database software is being used; ActiveRecord takes care of the vendor-specific differences.
Those are some specific things that make Rails so nice for web and database development. One of the hardest things for some people is getting used to NOT writing so much repetitive code.
That’s at the top of my list. What do you love about Ruby and Rails? Comments are open.
Testability, Simply
Here’s another real-life example of applying Agile values and principles in weird or hostile environments. You can adapt well-known Agile practices or even make up your own. The values and principles are what matter.
That’s what my game is
My idol Naomi Dunford suggested that my fans and readers might not be clear on what I do and why it might matter to them. This makes me sad, because I want to be known for more than throwing rhetorical bombs on Twitter.
Don’t get me wrong, that guy deserved the slam on Twitter, seriously, but slamming isn’t my game. It’s not my whole game anyway.
So let me go answer some of Naomi’s questions here. Go ahead and fire back in the comments.
Q. What’s your game? What do you do?
A. Short answer: I take software projects that suck and make them not suck.
Real answer: Look, life is really hard. I’ve been working on one thing and the next, in about fifty organizations over the last fifteen years, and the same freakin’ things come up over and over again:
- Everyone’s tired.
- Everyone’s afraid for their job.
- Everyone’s wasting time spinning wheels on stuff that doesn’t work.
- Every software project is running late and pissing off the boss.
- Every boss feels betrayed.
- Every developer feels oppressed.
- Software projects suck.
And I’m going huh. That shouldn’t be happening. I mean, this is ostensibly a “first world” country with tons of resources and lots of educated people who can do stuff. Software itself is complicated, but it shouldn’t be as hard as everyone is making it. Very often, we really do know how to make it better but for any of a thousand reasons doing the right thing seems to be beyond us.
And that’s my calling. It’s really quite simple. I take the things that are already actually known about making software projects go well and apply them to real life, so regular people can solve problems, live better, and maintain a certain level of sanity at work.
Q. Why do you do it? Do you love it, or do you just have one of those creepy knacks?
A. That’s a weird question, Naomi.
I happen to love having knacks for certain things. Is that creepy?
Also, I am in it for the love and the hugs. It’s so cool when I can help decrease the project suck factor so much they’re sad to see me go.
Q. Who are your customers? What kind of people would need or want what you offer?
A. If you manage, pay for, specify, benefit from, or try to oversee a software development project, and it sucks, we should totally talk.
Things that make you much more likely to benefit from working with me:
- sense of adventure
- willingness to be surprised
- reasonable level of vulnerability
Things that make it very unlikely that you will benefit from working with me:
- rather be comfortable than successful
- like to be in control
- quick to make up your mind about things
- quite certain it’s not you
Not to go all New-Agey on you here, but Making Software Projects Not Suck is rarely just a matter of plugging away at code. I’ve had a few of those, but most of the time the problems are way deeper than that. Sometimes the things that Make Your Project Suck are the exact same things you love about the project: drama! action! involvement! Then you have to choose: would you rather have the drama or the success? Because having both is not an option.
I’ve even dealt with projects that, when you cut through the crap, are supposed to suck. Like one in which the lead developer was under the impression his job would end when the project did. Or one in which the project manager seriously couldn’t figure out how to live without the angst and panic. And there was the time–I’m not real sure about this one–but there was this kind of indentured-programmer setup and the boss kind of liked it that way. It was power.
So number one, the thing that totally stands out as the most important distinction, is that you have to want your project to not suck and you have to be willing to change. Okay, that’s actually two things.
Does that sound like therapy?
I guess it does. I’ve got people you can work with if what you want is real head-shrinking. That’s not my bag.
What is my bag is showing you the truth. Things like:
- control isn’t progress
- action isn’t accomplishment
- progress isn’t a deliverable
If you’re up for that kind of challenge, let’s do it. If that scares you, then we should definitely do it. Buck up.
Q. What’s your marketing USP? Why should I buy from you instead of the other losers?
A. Losers? There are no losers in this.
But here are a few things that make my services unique:
- I help you get started using Agile practices (and feeling the Agile principles) at the tactical level. You can try one thing at a time–such as starting with pair programming–without having to commit to some big revolutionary cultural shift. It’s fine to experiment first.
- I’m attracted to, and effective with, the high-stress projects that make people crazy. I tone down the hype and make it easy to keep working instead of panicking. I’m anti-drama.
- Unlike a lot of shops that offer “Agile coaching,” you can see my terms and fees up front, like here and here. I just think it would be weird to hide things like that in the sales cycle when so much of what I do is make your practices transparent. I’m asking you to open your shop and your mind. The least I can do is be upfront about my side of the exchange.
- I still write software myself most days. It’s not theory.
- There is homemade Indian food on Fridays, even though some purists object to the hot reddish-orange cast of my special aloogobi recipe. (It’s traditionally a yellow curry, and mild.)
Q. What’s next for you? What’s the big plan?
A. So glad you asked! I’m doing two things to make Project Desuckification more accessible even when I’m not.
The first thing
The first thing is that I’m documenting my processes a lot more diligently than I used to.
For example: before, I’d ask a few dozen questions before doing anything else with a new client. Now I write down a few dozen questions before asking. In a very recent meeting, I planned the whole interview, then diverged from the plan to follow some tangents, then got back to the plan so I could finish (almost) all of the questions.
That accomplished two things:
- I remembered to ask about some less-immediately obvious things that would have flown out of my head in the give and take of the conversation.
- I have a handy list as a jumping-off point for the next such initial meeting.
I’ll refine and augment the list in using it a few more times on successive projects. Before long it will be easy to turn that set of questions into a checklist, an article, a NOTACON presentation, or maybe even a Prfessor course.
So it goes with the other artifacts of Desucking: the emails that explain pair programming, my notes from debriefings, a particularly amusing burndown chart, bits of open source code. They’re resources for the next gig, but they’re also inputs for the next consolidated offering. Their specificity is what makes them so valuable; their universality is what makes them so useful.
At this point you’re probably wondering how I get away with ripping off all this stuff from clients who pay me to keep things private. I don’t do that! In fact, depending on the assignment, I ask them to join in my famous “Disclosure Agreement.” It protects their proprietary and confidential information, but makes clear that I can talk, blog, and publish everything else about the project. It’s like compost for desucking: useless where it came from, but invaluable for the next cycle.
The other thing
The other thing is simple timeline planning. Sure, I’m thrilled to death to help when your project already sucks. That’s my Thing. But unfortunately, projects reach the ultimate sucking point at unpredictable times, and there’s only one of me. They tend to pile up, and I have to turn someone down, and then their project still sucks.
So now I’m developing ways to make your project not suck before it even starts to suck. They’re principles and techniques that work at any time, are easy to implement, don’t require a lot of overhead, and make everyone more productive with less hassle.
That way I can plan ahead a little, and the potential clients can relax if I’m not right on the spot when things start to sink.
Most importantly and immediately, I’m developing some resources to help your team learn pair programming relatively quickly and get the most benefit from it. So far I’ve found that pairing is a very low-cost and simple way to get started with the Agile concept.
My research question: The managers who resist pair programming the most are the ones who just can’t wrap their heads around Agility. True or false?
So…
There it is. That’s my game. Wanna play? It’s easy (and free) to start. Just dive into the comments, and if my way intrigues you, take a nice swim in the “Contrarian Guide to Making Software Projects Not Suck,” even though it’s an opt-in link. Because the weekly emails are even more fun than what’s on the blog.
What to ask first
Oh my. Here’s a Project That Sucks. It sucks so much I seriously don’t (yet) know how to make it not suck. How crazy is that?
Good thing I that Making It Not Suck isn’t the immediate task. My job now is Figuring Out How It Might Potentially Be Made To Not Suck. In other words, it’s a pre-desucking evaluation. The deliverables: one report with a recommended technical process, and one report with business recommendations.
When they won’t let you do Agile
If you’re a fan here, or if you’ve had more concrete experiences of working on Agile software teams, you probably have a good sense of how well the Agile values and practices can really work.
Problem: Not everybody sees that. Especially (perhaps) your boss or project sponsor.
The W part of DTSTTCPW
A couple of weeks ago, a question turned up on the BaseCamp site we use to coordinate one of my projects. One programmer asked what we thought of a certain calculation he was setting up on the database. It had to do with accumulating “rating” points of an item in a tree-shaped threaded discussion.
