Author: David

I walked to American Title Thursday morning and, after signing my name several times, am the proud new owner of unit #703 at Nelson Towers in Jackson. Well, that plus 10 years of mortgage payments. I moved a few things over after work: kitchen items, chairs, and a card table. I have Friday off work, so I might be able to move enough stuff to start living there right away. I’ve been asked a few times about when I’m planning to move in, and I don’t really have plans…. I’m just going to do it. Since I don’t have many possessions and it is not far away, it should be pretty easy. I suspect this post is pretty boring for most people, but I’m geeked.

Despite the long time since the last post, I am alive and well. I finished my senior thesis project back in September and early October. Tricia left for her mission in Argentina. I have been travelling for the past 5 weeks: one week in Florida, about a week in California, and a 3-week overland tour through South Africa with Swaziland and Lesotho. (Pictures are online now.) I arrived home yesterday after 25 hours on planes and 8 hours in airports for the return trip. Whew!

I am going with my family to Toronto for the weekend. Other significant events in the near future are starting a permanent position at Consumers on Wednesday, Dec. 1 and participating in commencement ceremonies at Kettering on Friday, Dec. 3. Today I also paid the deposit for my missions trip to Haiti in February.

This term at Kettering I am taking Software Engineering. I’m pretty geeked about it. I was not previously aware of exactly what software engineering was. I know that the developers at my company use fancy acronyms like SDLC and PMM that don’t seem to really mean much. We have two required texts for the course: The Mythical Man-Month by Brooks and Object-Oriented and Classical Software Engineering by Schach. In the past week, I have read about 150 pages of Brooks and maybe 60 pages of Schach. The term “Software Engineering” seems to have been created because of this problem: large software projects generally run late, over-budget, and create products riddled with bugs. This can be compared with other types of engineering, which appear to have better management, design, and products. (As I am writing this, dozens of engineering failings come to mind ranging from life-ending mistakes at NASA to little things like my car having a rough idle. However, I must admit that engineered building rarely randomly collapse; Windows crashes much more often.)

Brooks concedes that an individual or team of two can write wonderful software. The problem seems to arise when a large project is needed in a short amount of time. The solution is to form a large team to build the software– which is also the source of them problem. Schach seems to implicitly agree, but I haven’t read where he admits small programs could be over-engineered.

Schach repeatedly cites a statistic that 67% of a software budget is spent on maintenance — more than all the other phases combined (requirements, analysis, design, implementation, integration, and retirement).

As I go through this information, I am trying to relate it to my work experience. (As a Kettering student, I have almost two years of fulltime work experience in my field, unlike a typical undergraduate.) Right now I’m thinking the whole software life-cycle idea is very short-sighted. Maybe things will change as I keep reading, but the life-cycle process seems to assume it is operating in a vacuum. The beginning steps are aimed at a client requesting a new software product. While my company has a large IT department, brand new software products are rarities. The only one that comes to mind was the company website created a handful of years ago. Instead of new product requests, we have transformations of existing products and integration of third-party software products. I suppose the transformations are considered maintenance. I do not know what Schach thinks of third-party software products….

Let me digress about maintenance. As I stated before, it seems that the software life-cycle is focused on just new stuff. That means new versions short of complete rewrites are considered maintenance. If we apply that to Microsoft Windows, I guess the requirements, analysis, design, implementation, and integration occurred prior to the 1985 release of version 1.0. Does anybody out there agree with me? I doubt it. From what I have learned so far (which is admittedly relatively small), the software life-cycle does not adequately account for new major versions of software. They are too big to be considered maintenance, but too small to be considered new products. This is a big hole because nearly all software is released in versions. (Some of software life-cycles discussed by Schach accomodate multiple builds of a product, but that is a much smaller scale.)

In my previous work experience, I installed a third-party critical event notification product. It was a small project but still complex; its human and automatic interfaces had to be programmed. The human interfaces involved the way the product communicated with people via pages, phone calls, and e-mails. The automatic interfaces involved how it received events from a separate problem ticket product and later updated the tickets. The problem ticket product in turn interfaced with a network management product.

So far, I don’t see how my past project fits into the world of software engineering. I certainly did not design and program a new software product. However, there were definitely elements of design, implementation, and integration involved. The three big pieces were each “completed&qout; software products (according to the life-cycle), although they all allow for much customization. If the goal of software engineering is to produce a good software product, what do you call it when the goal is to produce a good system of integrated software products? Is it business or information systems or industrial engineering? This work has the same technical demands as software engineering, but the scope is one step bigger.

One possible way to describe this scenario is simply *using* the software products. Despite some work involved in implementing the interfaces, each product was designed to interface with multiple other products after all. So far, I haven’t seen where usage fits in to the software life-cycle. Is it really a good idea to completely ignore it?

On Friday I went home during lunch and prepared chili for dinner. I just bought some new spices, and I was looking forward to trying them out. My two choices were chipotle chile powder and jamaican jerk. After careful smelling, the consensus was that these two spices are not to be combined. My dad preferred the chipotle, so I went with that. Before cooking the meat, I heated up some oil with chipotle and minced onions on the skillet. More about that in a minute. I browned the ground sirloin and put it in the crock pot along with 2 cans of black beans, 2 cans of diced tomatoes, a can of tomato sauce, a tablespoon of chipotle chile powder, and a tablespoon of generic chili powder. When I got home from work in the evening, the house had a definite smell. The smell was similar to chipotle but kinda bad… sort of a burnt smell. This was not a good sign for the chili. Fortunately, the chili itself smelled fine and tasted great. The best I can guess is that the smell in the kitched was a result of burning some of the spice while I was heating it up on the skillet. Hopefully the smell will fade before too long.

On a different subject, I’ve been thinking about how Valentine’s Day is such a great opportunity to ask someone on a date. The conversation would go something like this:

• Him: So do you have big plans for Valentine’s?

Possibility 1:

• Her: Yeah, I do
• Him: Really? What do you have planned?
• Her: Well, I’ll be going out with my boyfriend to such and such……

Possibility 2:

• Her: No, not really.
• Him: Really? A beautiful girl like you with no date?
• Her: Nope.
• Her: What about you?
• Him: No, I don’t have any plans.
• *awkward silence*
• Him: Want to hang out on Valentine’s? I know this great restaurant…

Either way, you’re better off than you started. In the first possibility, you at least learn more about her. With the second possibility, there is so much upside. First, you don’t have to necessarily call it a date; it’s just spending time together and avoiding being alone on Valentine’s Day. Second, if it does work out, well then it is a date. 🙂 Regardless of the outcome, you leave yourself less exposed than if you asked this any other week; asking someone about their Valentine’s plans is casual conversation, whereas asking them about their Saturday night plans and then suggesting something has no subtlety.

Wondering if it worked? Well, I never got the chance to use this on the person I was hoping to, so I guess we won’t know.