I’ve been underground and off the blog for quite a while now. A lot of distractions have been going on, and the biggest project over my last couple of years has been under heavy non-disclosure, so there hasn’t been much to write about and even less time to write it in.
But one of the biggest distractions is on its way out. That’s right… the criticalresults.com server is getting an upgrade! Yay!
Continue reading “Adventures in Unix administration”
You can’t afford to: create the installer, finish the release notes, and tie up all those little loose ends. Not for every increment. It takes a long time and the effort simply isn’t worth it.
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.
Continue reading “Cost of convergence”
Why do we have standards that assume people are trying to get away with doing less work, crappy work, and that they prefer to be selfish about it? These work rules are brute-force solutions to a problem that doesn’t really exist.
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.
Continue reading “Rules for nothing”
The key to making your project not suck is making sure you’re solving the right problem. Start by doing the things that cost little, can’t hurt, and might help!
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.
Where it came from
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.
Continue reading “Solving the right problem”
I’m not sold on the very common corporate practice of requiring all database access to go through stored procedures. It’s not particularly efficient, it creates a lot of extra work for tiny benefits, and it cultivates code that’s duplicated and hard to find.
Now and then I check into The Daily WTF, partly because it’s funny and partly because it makes me feel a little better about some of the crazy code I’ve observed or been asked to maintain.
One in particular from about seven years ago amused me greatly, but not just in the train-wreck sense for a change. It addressed the very serious subject of putting all your database code into stored procedures. The comments are actually pretty illuminating.
Alex Papadimolous, actually being serious, wrote:
Though they take a bit more time to develop upfront, using database stored procedures are definitely the way to go for most information systems. They provide a looser coupling to the “data layer” by limiting the points of entry and offer stronger cohesion by breaking operations into reusable functionality.
I don’t think so, if by “most information systems” you mean the typical multi-tier business and financial databases that most of us maintain in our day jobs. I find that the looser coupling is almost always theoretical; it breaks down when you have to look at code from a year or two ago and figure out what the underlying stored procedure is actually doing instead of what you expect.
Continue reading “Stored Procedures aren't all that”
Software projects go badly when everyone is unrealistic about how real humans do creative work.
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.
Continue reading “How did we get into this mess?”