Alex's Soapbox

If you've been following The Daily WTF for the past couple years, you may have noticed an ad or two for Inedo or BuildMaster. But what you probably didn't know (at least, according to those I've met in person), is that Inedo is actually my company, and BuildMaster is the product I designed.

Ask WTF: Salary

Some IT problems are easier to solve than others. And some might be downright impossible, like this letter:
Most of the emails that arrive in The Daily WTF inbox are some kind of a submission. Or a hate mail. But every now and then, some one will request something a bit out of the ordinary: advice.
Throughout my software development career, I’ve seen my fair share of debates over how databases should be developed. And like most disagreements over technical pedantry, the participants are generally well-intentioned but grossly inexperienced. So much so that it wouldn’t matter if they use foreign keys or not. Though “elegant”, their software will become an unmaintainable mess after a few short years. But regardless, one counter-argument that constantly rears its ugly head goes something like, “but what if we have to change it later?”
Your introduction to source control probably was a lot like mine: “here’s how you open SourceSafe, here’s your login, and here’s how you get your files... now get to work.”
I was having lunch with a colleague the other day when his phone rang with the distinctive office ringtone. Rolling his eyes, he excused himself to take the call. It was just a run-of-the mill workplace emergency, but there was one thing he said that I couldn’t help overhearing: “fine! I guess we’ll just do a new release for QA.”

Testing Done Right

It’s been a rough couple weeks. Not only did I have all sorts of catching-up to do after Code PaLOUsa, but it also happened to be release week. And oh, do I hate release week.
Of all people, I have a pretty high standard for doing things right. After all, I’m probably the last person who wants to be caught being The real WTF. This makes things tricky at the Day Job, <shameless_plug>where I work on BuildMaster, a pretty cool system that streamlines and automates the entire development, build, test, and deployment processes.</shameless_plug>, as I’ll often spend an exorbitant amount of time wondering about the best way to do something. Case in point: what’s the right way to do documentation?

Patterns of Failure

Not too long ago, I was at a client site, working to understand and improve their development process. From a birds-eye view, their development organization was a lot like many other Corporate IT set-ups: they had a sizable portfolio of proprietary applications that were built for and used by different business groups. Some of these applications were “mission critical” and had highly formalized promotion and deployment processes, while others were ancillary and were hardly ever used. <shameless_plug>This, along with the medley of technologies and platforms, was why they sought our help in managing and automating their development processes with BuildMaster.</shameless_plug>
Programming is not fun. It’s boring, it’s tedious, and it’s certainly not challenging. And no matter how much you stretch it, programming is most definitely not sexy.
If you’ve worked at enough companies in the IT industry, you’ve probably noticed that the most talented software developers tend to not stick around at one place for too long. The least talented folks, on the other hand, entrench themselves deep within the organization, often building beachheads of bad code that no sane developer would dare go near, all the while ensuring their own job security and screwing up just enough times not to get fired.
As most development managers know, the FBI's Virtual Case File (VCF) system has become the epitome of the software industry's most expensive failed project. Running taxpayers between $100 and $200 million dollars over four years, the VCF delivered little more than a mountain of useless documentation, nearly a million lines of code that will never run in production and a whole lot of costly lessons. Worse still, the lessons offered from this multi-million dollar failure could have just as easily been found in a $50 software engineering textbook. In fact, the major factors behind VCF's failure read much like such a book's table of contents: Enterprise Architecture: VCF had none. Management: Developers were both poorly managed and micromanaged. Skilled Personnel: Managers and engineers with no formal training were placed in critical roles. Requirements: They were constantly being changed. Scope Creep: New features were added even after the project was behind schedule. Steady Team: More people were constantly added to the team in an attempt to speed the project.
If you’ve developed software for long enough, you’ve most certainly heard of a “business logic layer.” It’s supposed to be the layer (or “tier”) containing an application’s business logic and is sandwiched between a “persistence layer” and a “presentation layer.” Some call that the “standard three tiers of an application.” But what it really is, however, is a bad design that leads to bad software. Or at the very least, dangerously poor semantics. In lieu of your standard WTF article, allow me to explain why.
Many years back, I got hooked in to whole the Atkins Diet craze. And like most dieters, it didn’t work. I lost weight and slowly gained it back over the next few years. The reason that Atkins – and all the other fad diets – fail is because they try to avoid a simple, painful truth: short of altering body physiology, the only way to lose weight is to eat less and exercise more.

Soft Coding

The submission behind today's schedule article was withdrawn; instead, I'd like to take this opportunity to present the practice of Soft Coding.
Earlier this week, I changed the name of the site to Worse Than Failure. A lot of readers weren’t too happy with the new name and many of you wondered why, of all names, did I choose Worse Than Failure. After all, what could possibly be worse than failure? In lieu of telling a specific story of failure today, I’d like to share my insights as to why there are – and will continue to be – so many spectacular WTFs (as in, for old time’s sake, What-The-F*s) in our industry, and why so many of them are, in fact, worse than failure.