So I spent a lot of the weekend refactoring my Healthy Homes database system. (I know, what a party animal.) And after getting some solid work checked in, I realized it was definitely time to do a major refactoring of the Data Access Layer (DAL) code.
I got a kick out of today’s XKCD comic strip. (Chart: “How long can you work on making a routine task more efficient before you’re spending more time than you save?”) It reminds me a lot of a conversation I had last Friday with an entrepreneur who’s trying to automate some, but not all! of his information business.
See, “Allan” gets a lot of documents that are not so well standardized, puts their contents into a database, and essentially gets paid by his client companies to let them know when and where they–or their subsidiaries–are mentioned. (There’s more to it than that, but this is the relevant part right now.)
My college homie Dave is working on the “Minimum Viable Product” (MVP) version of his Baqbeat product. I’m always interested in what old friends are doing, so I asked him about it.
Baqbeat is a little hard to describe. Dave filled me in:
Baqbeat generates timelines of configuration changes to all the servers in
your development and operations environments – version control, build
servers, app servers, databases, and others. It automatically infers
related events on different timelines. So for example, you can see problems
in your production environment and immediately trace it to the code change
that broke it.
(tl;dr: Answer a few easy questions to see if I can help your startup!)
Do you have a startup company that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Are you still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?
So you have this small business. You probably just started it. You’ve got a pretty good business plan, you’ve stashed some money to keep it going until it breaks even and can pay you, you’ve worked out health insurance and stuff… or maybe you’re keeping your day job and working a lot of nights and weekends to get it together. And it’s a cool idea: some product or service that people are definitely going to want to pay money for. It’s exciting and terrifying, because you don’t know what could go wrong, but you’re also a little apprehensive about how it will go right in the end.
Well! I just spent a lot of time with various tech-related startup companies. Some of them have Projects That Suck; others are simply getting started with new things. I’ve learned a lot more about what does and doesn’t work, and I’m ready to share the results with you.
Do you have a startup that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?
If this sounds like you, watch here next Wednesday for the plan and the details. We can work together to get your startup project on track, within budget, and under control. I’m really excited about this. I think you will be too.
I was recently developing a significant new feature on an ASP.NET application. The client’s regular dev team is located in India, but for this new feature they wanted somebody whom they could work with face-to-face, and having me dedicated to the project (for a short time) seemed like an advantage.
We started off really well. I was able to get into TFS for version control, connect to the development database, and add a few basic pages to get started.
One blog entry from last year, “Look. This SOPA/PIPA Thing,” started out as an offhand blurb on my Facebook status. I think I spent two whole minutes writing it, which can be pretty effective when you know exactly what you want to say:
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.
My favorite comment came from my old Grinnell College homie, Laura Allender Ferguson, who said simply: “Go Agile.” She was responding to my side-whine about the ever-changing requirements that we always get from software development clients.
For several years now, I’ve been describing my business as “Making Your Software Project Not Suck.” Here’s where that catchphrase came from, and how I actually go about doing that.
Maybe twelve years ago… yeah, okay, that would have been in the lull after the post-Y2K slowdown and just before 9/11… I was pretty much in between major projects. As was almost everyone else.
It was time to Work on Marketing! Which if you’re smart, is something you do all the time, but in some ways I’m just not that smart. Or more to the point, I do know what I have to do but there are always competing priorities that appear to be more urgent. You know how it goes. Fire-fighting often trumps planning.
I’m in the midst of an email conversation with a pretty well-known turnaround CEO adviser, the kind of person who can Make Your Company Not Suck. He’s way beyond me in terms of influence and reach, and he consults enterprise-wide for way bigger outfits, but for some reason he ended up asking me why so many projects still get in trouble even though all kinds of training and certification are available these days.
This is about what I wrote back.
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 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.)
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.)
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.