One of the many things that is in my backlog of things to do is write up a guide for proper/advanced use of version control system repositories for 3rd year software engineering students at my university. Hopefully I might be more motivated to finish it if I create it in a series of blog posts. I’m sure others might be interested in this topic as well and, if you have any suggestions or queries, provide feedback in the comments!
This is a more general reading list for software engineers than my previous book lists that covers articles, essays, blog posts and journal papers. Because I’m planning ahead, I’m calling this Part 1 and expecting more lists to come in the future.
Recently at my university, the fourth year students had the excellent idea of having a trivia night to help study for their upcoming Software Project Management exam. From the sounds of it the night went fairly well - I think anything that making studying even marginally fun is to be applauded. The questions were taken from the subject text book and one seems to have generated some controversy. The question was what is the difference between incremental and iterative lifecycles?
We all search for meaning in things. Software development seems to be an exception. Some of the things I’ve seen make me wonder if the people responsible ever took a step back and thought “what is the reason for this?” At a very basic level the understanding and contemplation of the meaning of a thing allows you to use that thing far more effectively than you otherwise could, or to know when and when not to use it. Alternatively, and from a more artistic point of view, trying to understand the meaning of something gives you a deeper connection with it and gives you a greater range of expression with it.
The study of meanings, according to Webster, is called semantics. I’d like to try and elaborate on a few simple points where I think looking at the semantics of something would improve software development practices, including student work.
I was skimming through Death March today and was reading a bit on specifications and one thing kind of jumped out at me. I have been thinking a lot about risk management lately, mostly since I recently had to write a workshop handout for the 3rd year students, so this struck me as rather interesting. The thing that jumped out at me was that Yourdon suggests specifying risks associated with requirements as part of the requirements specification.