Makefiles. Why Projects Fail. Process. Etc.

It feels like spring today.

This year is turning out to be like the last. There are still no flowers, although the bulbs we planted last autumn are pushing through the ground. The leaves will likely come late, too, despite budding after a 70 degree day in January.

Even though it might snow tonight, I’ve come out of my den to look around and survey a winter’s worth of earnest work. Here are some random thoughts mostly in a software engineering vein that I’ve had over the long, cold winter. (If you’re looking for something related to human vision, consider V1, a site about “the primary visual cortex.” If you come here for photography, stay tuned.)

Makefiles are what UNIX-based programmers (and ambitious Windows programmers) use to build software, manage dependencies, and create a common set of compilation parameters. Working with makefiles is hard, and I think that most of the difficulty comes down to the difference between imperative versus declarative languages.

In the real nonacademic world more than 99% of software developers develop applications in imperative languages, where you tell the system how you want it to do things. Makefiles take a radically different approach. As a declarative language, you tell what you want the result to be and then leave it up to the make application to figure out how to do it. It takes a bit of brain rewiring to shift from working with code where you can trace what’s happening to code where you look at the inputs, the desired outputs and the parameters. It’s a shift from knowing what individual commands do to knowing how the whole system works behind the scenes.

Construx Software, Steve McConnell’s software best practices company, published a white paper on classic software engineering project mistakes a couple months ago. I participated in the survey and was interested in seeing the results. Here are the biggest mistakes according to risk exposure:

  1. Unrealistic expectations [2]
  2. Overly optimistic schedules [1]
  3. Short-changed quality assurance [4]
  4. Wishful thinking [7]
  5. Confusing estimates with targets [9]
  6. Excessive multi-tasking [3]
  7. Feature creep [6]
  8. Noisy, crowded offices [5]
  9. Abandoning planning under pressure [11]
  10. Insufficient risk management [8]

The numbers in square brackets are the ranks of how often the mistakes happen in projects.

Jeff Atwood posted a very interesting article about software process. He doesn’t come right out and say “Process! Bah, who needs it?” But he does invite a contrast between what professional software organizations need when they aim for process compliance and the open source projects that frequently shun repeatable processes. He also highlights the trade-off between process management and delivering features. The comments provide interesting food for thought for people seeking to optimize their process and/or deliver new features.

This is the final week of the spring semester. Shortly I’ll be 7/10 done with my software engineering program. This is my first semester without any theory classes, which is why I’ve had to go to the web for the deep insights. Instead, this semester I’ve been learning about the mysteries of UNIX programming: users, filesystems, processes, pipes, etc.

If all goes according to plan, my last three courses will be all C++ all the time, with an object-oriented design course thrown in for good measure. It’s nice how all of my courses have dove-tailed with what I’m doing at work. I’m going in a new direction at work, and I think this pattern of learning things I can use right away will continue. . . .

This entry was posted in Life Lessons, Software Engineering, Worthy Feeds. Bookmark the permalink.

3 Responses to Makefiles. Why Projects Fail. Process. Etc.

  1. mary says:

    i watched “helvetica” last week and thought of you. have you seen it?

  2. Jeff Mather says:

    I have seen “Helvetica,” and I liked it a lot. I have to confess a soft spot for modernist design and how it looks so clean and minimalist. So I’m naturally a sucker for sans serif fonts, like Helvetica and (especially) Gill Sans. But I also appreciated the way the film presented the viewpoint of modernist typefaces and design as soulless and bourgeois. I am a man of contradictions.

  3. mary says:

    i don’t think that’s a contradiction – you can be a fan of both minimalist fonts and super crazy shit that looks hand-drawn if you want :)

    i do like helvetica, and i like it even more after seeing the movie, but i am still big on serif fonts. i just love those extra little pixels!

    (did you have a hard time watching that one guy talk? i can’t remember his name, but his tongue was out of control – every time he came on screen, lizzy, adam, and i would hold up our hands to block his mouth. i swear we were not intoxicated!)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>