Software Development "worst practice"

[yesthattom]

Jim actually prototyped and demonstrated a software package that could automate and accomplish the entire deployment process in a fraction of the time and eliminate the possibility of human error. Naturally, he was shot down by one of the lead developers; actually, the very same lead who designed the whole branching and Merge Day process in the first place. His reason: “I made a makefile once in college; they’re more trouble than they’re worth.”

The Daily WTF, 2006-11-01

Why do I keep hearing that same story over and over. Why do I keep meeting people that “saved the company millions” by automating the build process so that is repeatable and fast, not a week-long process that stalls the entire company... but only did so after being told not to do it, or that it wasn’t worth it. kimuchi tells a great story like that. Others have too.

In both of my books I found excuses to mention “make” and “makefiles”. Sure, there are a million similar things out there. It doesn’t matter what you use, just as long as you aren’t manually typing command after error-prone command to get your software built.

WTF!

Comments

If not automated build, what else?

[rationalfool.livejournal.com]

I don't get it... what else would the "lead developer" want to do? Compile each file by hand? Copy them over to installations? I have heard (and experienced) my share of horror stories, but this one boggles even my mind...

Folks should try out Jam (from Perforce)... it's pretty nifty actually, but one unintended side-effect might be an appreciation of Make ;-).

Re: If not automated build, what else?

[kimuchi.livejournal.com]

*rocking back and forth in autistic fashion*

Nevermind me, you just triggered my post-bjam-stress disorder. Straight up jam may be OK (haven't really used it at length), but Boost's jam is designed to break build engineers' wills.

[misteropinion.livejournal.com]

I learned the glory of make in college still when my Assembly TA said, "OK, if you get this, you'll win: 'The children of batch are not subject to re-batching.'" This meant that if I did everything with one make, I didn't have to wait for the compile, assemble, and run progs to each be batched.

Of course now, all I hear is "ant ant ant ant ant". The glory of being the systems guy at a java shop...

[jwg.livejournal.com]

I've seen much worse.

After Multics was killed and a new OS project for the Honeywell mini computer line was also killed, in a reorganization I inherited a set mainstream products for this mini computer line. One of the products was a DataManagement Product where the source code was 5-years obsolete; they made bug fixes with binary patches! The first thing I did was to get someone to "sourcify" this mess which had hundreds of patches.

Apparently at some time a high-up manager decided to implement source code freeze very literally and this resulted in binary patches being used for final integration bug fixes. For various other reasons of bad practices the final stages took months because they had a Merge Quarter as part of their process.

The OS was sufficiently bad that different groups had to make many fixes to OS components while implementing/testing their stuff and each did it completely independently thus resulting in a complete mess. Oh yes, and most of this software was written in assembly language and they had no tools to help them do anything.

I was happy to take a different job in a research group a few months later.

[dglenn.livejournal.com]

Hell, I use 'make' to typeset music.

I have run into makefiles that were flawed, difficult to comprehend, and painful to debug. But c'mon; worst case, if your build is so impossibly complex that even the makefile gets hairy, go with a more cpu-wasteful but still programmer-kind script to automate things. Even when a project is "too simple to bother writing a makefile for", it's because I can regen it with a couple of '!' or up-arrow command-history keystrokes in tcsh, or I dump the three or four commands involved into a shell script.

[gravitrue.livejournal.com]

*Hobbit* used 'make' to make legal contracts for consulting gigs.

I've sometimes wondered if one could put a gui on this and make money selling it to lawyers. Not that I'd want lawyers as customers; would require too much effort to make sure unhappy clients didn't sue or try to weasel out of paying for things. Someone has probably tried it and lost.

[kimuchi.livejournal.com]

I should write that story up for non-friends-list consumption (not anything incriminating there, just y'know).

To be fair, though, almost every organization I've worked in has used make and/or ant in some fashion. Typically when I've come in projects have been set up well enough that most of the developers can compile and debug their component at their desks. What I do is the "release harness": automation to reliably and reproducibly check out, build, and package the software for release, with the side goal of making this entire process as transparent as possible so everyone has confidence as to what files/revisions exactly were checked out, where and how they were built, and which artifacts came from which build (surprisingly un-controlled in some places I've been...kinda scary). You *could* do most of what I do with make, but it's kind of a mess -- make's designed to build software, not release it.

No news here

[cpj.livejournal.com]

None of my developers really go for the automation stuff. There is one shell script that builds packages, but it's pretty ugly. And, there are no automated test cases either.

But that's okay, because I have an administrator that doesn't document crap, and we're all cursing the fact that he creates /var partitions that are only 2G in size, yet fill up to 1.5G after the automated install process.