All Alex's Soapbox

Alex's very own soapbox for all things software and technology.

02 Apr 2013

A (Long Overdue) BuildMaster Introduction

by Alex Papadimoulis in Alex's Soapbox on 2013-04-02

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.

I've always been a bit hesitant to talk about these on The Daily WTF. It's not that I think you'd mind, but I've always felt that you come here to read about curious perversions in information technology, not about my professional attempts at improving software development. So thank you in advance for reading this – if you've been reading for some time, you know I don't make a habit of this.

Five Years in the Making

49 Comments - Last Comment @ 06:48
02 Oct 2012

Ask WTF: Salary

by Remy Porter in Alex's Soapbox on 2012-10-02

Some IT problems are easier to solve than others. And some might be downright impossible, like this letter:

Dear WTF, I am a female web developer. That’s not the WTF. I’m honestly worried that I really am making only 71% of what my male co-workers are making. How can I know if this is true?

237 Comments - Last Comment @ 06:48
13 Sep 2012

Ask WTF: Learning The Business

by Alex Papadimoulis in Alex's Soapbox on 2012-09-13

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.

Hi Alex,

I recently started my first "grown-up" job as a software developer. 
As exciting as it is to get paid for doing what I love, I can't help but wonder 
if I'm expecting waaaay too from a company.

My main issue is that I know virtually nothing about the (very large) application 
I'm maintaining, or even the business domain. There is a business requirements wiki 
(and a whole team who can apparently answer questions about it), but it's filled 
with words and terms that are so domain-specific that it's basically impossible 
to get a proper understanding of things. It feels like I'm learning to fly using 
only blueprints to a Boeing 747.

I was really expecting that someone would sit down with me and give me a nice demo 
of the ins and outs of the application and the business, but no one seems to be 
willing or able to do that. Messing around with a test version of the application 
doesn't help either since there's no product documentation accessible and the little 
help that's available is littered with domain intensive keywords.

I feel that "it's complicated" and "this is a fast-paced environment" 
is no excuse to skip proper training and to not give due importance to knowledge 
transfer to new hires. I feel that if I were running the department, I'd accept 
the overhead and just make sure developers could understand the applications and 
business they're maintaining. Is this so much to ask?

How exactly am I supposed to understand the application if no one else seems to know 
(or be willing to share) what it does?

Sincerely,
S.N.

90 Comments - Last Comment @ 06:48
28 Feb 2012

Database Changes Done Right

by Alex Papadimoulis in Alex's Soapbox on 2012-02-28

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?”

In other debates, that question can be quickly rebutted with “uh, we just change it then,” but when the discussion is on databases, it actually holds water. It’s as if the database is a marble statue that, once shipped to production, should never be changed... and if it must, there had better be a damn good reason.

126 Comments - Last Comment @ 06:48
06 Sep 2011

Source Control Done Right

by Alex Papadimoulis in Alex's Soapbox on 2011-09-06

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.”

For the most part, that works just fine. We’re already familiar with the nature of files and directories, so introducing the concepts of checking-in and checking-out aren’t a huge leap. Repositories, merging, and committing become second-nature just as easily.

152 Comments - Last Comment @ 06:48
07 Jun 2011

Release Management Done Right

by Alex Papadimoulis in Alex's Soapbox on 2011-06-07

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.”

It stood out like nails on a chalkboard. “Huh, what do you mean?” he responded when I asked him about it, “they were trying to fix the build, but I dunno, they couldn’t, so I said to do a new release.”

90 Comments - Last Comment @ 06:48
22 Mar 2011

Testing Done Right

by Alex Papadimoulis in Alex's Soapbox on 2011-03-22

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.

Don’t get me wrong, I’m just as excited as anyone else when a new release of BuildMaster comes out (it was release 2.3, in case you were wondering), but new releases mean testing. And fixes. And more testing. And still more testing. And oh, do I hate testing.

211 Comments - Last Comment @ 06:48
05 Oct 2010

Documentation Done Right

by Alex Papadimoulis in Alex's Soapbox on 2010-10-05

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?

Just to be clear, by “documentation”, I don’t mean manuals, user guides, feature matrices, and the like. Those are produced by technical writers, who seemingly enjoy living in the third circle of hell. What I mean is UML, Data-Flow, Flow Charts, Module Breakdowns, and all other works used internally by the development organization. And expanding on the question, which of these documents are we supposed to produce, and how much documentation is needed?

Documentation Done Enterprisey

192 Comments - Last Comment @ 06:48
02 Mar 2010

Patterns of Failure

by Alex Papadimoulis in Alex's Soapbox on 2010-03-02

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>

But as I dug deeper, I noticed that a significant portion of their applications weren’t applications at all. They were – for lack of a better word – “modules” that glommed together to form an ÜberApplication. Completely unrelated business functions – paid time-off tracking and customer mailing list management – lived side-by-side, sharing authorization principals, navigation controls, and even a “business workflow engine.”

105 Comments - Last Comment @ 06:48
17 Feb 2009

Programming Sucks! Or At Least, It Ought To

by Alex Papadimoulis in Alex's Soapbox on 2009-02-17

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.

I know what you’re thinking. Anyone who says that – let alone blogs it – should immediately be stripped of his software development license, have his keyboard taken away, and be permitted to only use only to CP/M on 8" floppies with a 1200 baud modem.

286 Comments - Last Comment @ 06:48
29 Apr 2008

Up or Out: Solving the IT Turnover Crisis

by Alex Papadimoulis in Alex's Soapbox on 2008-04-29

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.

Earlier this month, Bruce F. Webster aptly named this phenomenon the Dead Sea Effect. Today, I’ll discuss a solution to overcoming it. In short: embrace turnover, encourage separation, and don’t even think about saying “careers, not jobs.” Oh yes, it’s Employment 2.0.

171 Comments - Last Comment @ 06:48
09 Oct 2007

Avoiding Development Disasters

by Alex Papadimoulis in Alex's Soapbox on 2007-10-09

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.

While these are all valuable lessons that every development manager should take to heart, one of the most important -- and certainly least discussed -- lessons stems from one of the rare correct decisions made on the project: the decision to cut bait and scrap the whole thing.

120 Comments - Last Comment @ 06:48
25 Sep 2007

The Mythical Business Layer

by Alex Papadimoulis in Alex's Soapbox on 2007-09-25

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.

First and foremost, we need to define the term “business logic.” Unlike so many other entries in the IT lexicon, “business logic” has no standard meaning. We’re left with what you think it is, what your colleague wants it to be, and what some article you read says it is. So, for the purpose of this article (and hopefully beyond), here is my definitive definition.

236 Comments - Last Comment @ 06:48
24 May 2007

The Great Pyramid of Agile

by Alex Papadimoulis in Alex's Soapbox on 2007-05-24

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.

In the past decade or so, we’ve seen a lot of “fad development methodologies” crop up. In lieu of a standard Worse Than Failure article, I'd like to discuss the latest craze (well, for a few years now): Agile and its derivative methodologies. They all promise the same thing – cheaper, better software built faster – and they all generally fail to deliver. Like fad diets, these methodologies try to avoid a simple, painful truth: you have to know what to build before you can start building it.

241 Comments - Last Comment @ 06:48
10 Apr 2007

Soft Coding

by Alex Papadimoulis in Alex's Soapbox on 2007-04-10

The submission behind today's schedule article was withdrawn; instead, I'd like to take this opportunity to present the practice of Soft Coding.

Most programmers consider “Hard Coding” to be a Bad Thing: it’s hack-like, inelegant, and all-around lazy code. And as such, many programmers try their damnedest to avoid it. Unfortunately, this quest of avoidance often leads towards a much worse path: complication, convolution, and all-around unmaintainable code. It’s a path I like to call Soft Coding.

232 Comments - Last Comment @ 06:48
28 Feb 2007

What Could Possibly Be Worse Than Failure?

by Alex Papadimoulis in Alex's Soapbox on 2007-02-28

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.

In the almost-three years that I’ve been writing this blog, I have seen some of the most obscene perversions in information technology ever created. Heck, we all have. While quite a number of these disasters can be blamed on amateurish incompetence, so many defy all explanation. It’s as if highly-capable, incredibly-intelligent, and good-natured software engineers got together and said, "Let’s build the worst software ever created!"

116 Comments - Last Comment @ 06:48