Homework 9 – Software Engineering – CSCI 362-001

I suppose previously I hadn't considered the four areas of “The Programming Systems Product”, aka the program, Programming Product, Programming System, and Programming Systems Product. I'd always been aware that when someone was toting about having made some amazing program that's cheaper and works better than those that are commercially available that it was probably missing a great deal of something – though I hadn't really considered that maybe it was a different type of product all together.

I agree that turning non-tactile thoughts into real results is something that is is one of the most enjoyable things about programming. I also agree that there are quite a few things that seem to make it frustrating – always working for others, always being outdated, spending large amounts of time finding bugs. I also find that optimism in our craft is...silly. It would seem to me that you want to be cautious about what you guarantee and you want to be 100% sure you can give what you promise – if you're an optimist or take their approach, you seem to be shooting yourself in the foot in that regard. Especially in something where you have to test repeatably to see how often it's reliable – why would you assume something is fixed or done before you've tried again?

I think overseers of software development projects don't always understand what is going on to make their project happen. Needless to say it's rather agreeable to me that any month and any man are interchangeable. Not only is each person different, each month a different length with different variables, but the problems and progress that needs to be made is different at each different point in time.

Communication seems to be one of the biggest reasons for software failure – though this book gets into some detail about why communication isn't just “easy”. It also goes into why adding people to a failing project is a bad idea – not all problems can be solved with more people, and if communication is already bad, more people are only going to make it worse since far more has to be done to keep more people up to date.

I'm not sure how most schedules for software projects usually are planned, but lots of testing time seems important. It seems most failures are because of poor design and not enough testing – it seems logical that these areas are given the most manpower when planning allocation.

Better, smarter, smaller teams being preferred over larger more mediocre teams is also something that seems like common sense and has been something taught to us over and over. More people means seaming together more partitions, more training, less responsibility and more effort in communication. While it's true this means really large systems won't be completed in time for them to be used or useful, I imagine there are a lot more smaller projects being designed and developed than extremely large ones.

Mill's way of splitting up work and getting a project done sounds like it's...very neat. Neat in a sense of organization and responsibility, which I enjoy. That being said, this team, especially with the “surgeon”, sounds very risky – consequences could be severe if he was to quit or leave. I'm not sure how more business manages are willing to risk in regards to this – it's very much like putting all your eggs in one basket.