Wednesday, February 25, 2004

SCENE Conference

I gave a talk at the SCENE Conference in Philadelphia on Saturday, February 21st. SCENE stands for Student Chapter Event - Northeast, and it was an all day event where the ACM student chapters from universities in the Northeast met and attended presentations on a central theme (AI this year). This is the abstract:



Artificial Intelligence has been an active part of the computing industry for three decades. I will provide a personal view of AI in industry over that time, highlighting both the engineering and research aspects, compare it to AI at the university and offer advice for anyone making the transition from the university to industry. I also will speculate on the future of AI in industry.





You can download the pdf here. Rather than starting a new blog for AI I am adding it to this blog under the category artificial intelligence.



Tuesday, February 24, 2004

Coding Standards

In our last class I mentioned that it is useful to get developers to agree on coding standards, so they are not constantly arguing about indentation styles and naming conventions for variables, classes, methods, ... Lynn Rider's entry which follows shows that something that is well intentioned when taken to the extreme can result in a miserable experience! This is a great (and well told) example of how we can all learn from our experiences. Thanks Lynn!



In Monday night's class, you were talking about how coding standards should be defined 'well' in the beginning, before any coding is ever done. You made a claim that this can save you 3 weeks of time in the long run, as developers love to hash out what is better, more efficient, readable, etc...Although I can see the value in what you said, this brought to mind something that I remember from my internship 2 years ago.



I was working for a company for a few months to fulfill my internship credits for graduation. The company is very well known and takes on mostly defense contracts. When I first got there, my very first day, they handed me two documents to read. The first was their CMMI folder, they happened to be a Level 5. The second they handed me was and Ada Coding Standards document, that was given to them by the government as a standard way to write Ada code when they are working on defense contracts. I was impressed that they were on a level 5 and that they were so precise in how someone should write any little bit of code. I actually enjoyed reading the second book, as it not only told you how to do something, it told you why they wanted you to do it in that manner.



Down the line however, I ended up doing regular code reviews with the other members of our team. When we did code reviews, everyone on the team was involved, as well as the Software Verification people. These usually were slotted for 2 hours at a time, and page by painful page, we would go through all code changes, unit tests, and anything else someone wanted to bring up. If we weren't finished by the end of the 2 hours, we would schedule another 2 hours the next day, and would do this until it was done. There was one particular man in our group, that would sit there and pick apart every last thing. Sometimes he was correct, and sometimes I just think he wanted to be correct. Either way, there were many days I fantasized of that famous Looney-Tune 'anvil' to miraculously drop out of the sky and fall on his head, just so we could move on, often times more than once a day. He was a stickler for these Ada Coding Standards, and although most of the time he was right, there were many times I would bring this book to the meetings, just to stop the 'small war' between the developers. Was it the person? Was it the strict standards imposed by the government? Was it a little of both? And... was this good for us in the end?



For the most part, to me, keeping a standard in place seemed/seems like good idea, but when someone made it their goal in life to argue for 15 mins about the tense of wording in comments or capitalization of the first letter of an index on a for loop or he thought this name would be better suited for one variable or another... what I thought initially was a good thing, turned out to be burdensome and torturous, to say the least. I don't know that we saved time having coding standards in place or not in the long run, all I know is that it gave us more to disagree about, and unfortunately the 'anvil' never came to our rescue. :-)



Saturday, February 7, 2004

New Kind of Science

For those of you that do not read slashdot (and if you do not it is highly recommended and can be accessed here), one of the items yesterday was announcing that Stephen Wolfram's book, A New Kind of Science, is accessible for free here. All it requires is a short registration. The book is fairly recent and huge (1192 pages). Wolfram's concepts have elicited strong reactions. As the title suggests he does have a touch of ego. Nowithstanding he is one of the intellectual mileposts of our generation and it is worth exploring his ideas. Wolfram also is the creator of Mathematica, a superb but pricey math system and programming environment. Check it out. As I trudge through it, I will have more to say about it and also others reaction to it. Later.



Thursday, February 5, 2004

Software for the Stars

Greg Horvath in his Comment on Requirements Innovation cited an excellent article. The article is on NASA's software engineering efforts and was in the January issue of Computer. It can be found here. The article discusses a wide ranging set of efforts including formal specifications, code generation from specifications, state-based control architecture and human engineering of code.



Starting next week I will review some of the techniques listed in the article and provide you with resources to explore them further. I think the NASA work is particularly interesting since it is one of the few current attempts to integrate the full range of software engineering techniques into production. Until then check out the article and let me know your thoughts on which techniques you would like to explore in more depth. Later.