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.
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:
- Unrealistic expectations 
- Overly optimistic schedules 
- Short-changed quality assurance 
- Wishful thinking 
- Confusing estimates with targets 
- Excessive multi-tasking 
- Feature creep 
- Noisy, crowded offices 
- Abandoning planning under pressure 
- Insufficient risk management 
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. . . .