Resiliency in Supply Chain Networks

Andrew Smith and I have been looking at the problem of resiliency in supply chain networks. That is, given the fact that supply chains are formed by selfish agents who create links with others based on their own local interests, we cannot expect the resulting network to always have the optimal resiliency characteristics. It is quite possible that because everyone is acting myopically—agents care only about their immediate neighbors—that the resulting network will have some bad global properties. The global property Andrew studies first is resiliency, which we define as the ability of the network to withstand the loss of one node.

Andrew presented his paper titled A Practical Multiagent Model for Resilience in Commercial Supply Networks at the latest Agent-Mediated Electronic Conference. He implements a model which generates supply chain networks based on a well-known model from management theory, so the networks' topology should match real world networks, and then examines the resiliency of the resulting networks. The results are not surprising in the general sense (more connections mean more resiliency) but they do give us a quantitative measure of network resiliency.

Below are the slides from his presentation:

Software Engineering Projects

I am often surprised at what a small group of our Senior Computer majors can accomplish in one semester, while taking four other classes, looking for a full time job and, in many cases, also working a part time job. But, they do some pretty amazing things in my CSCE 492 class.

The first group this semester decided to build an iphone app. None of them had any experience with the Mac, or objective-C, or the xcode IDE, nor did any one of them even own a Mac! Still, none of this matters much. They quickly came up to speed on objective-C (which has similarities to many of the languages they learned in other classes) and managed to build a game that is better than many of the games in the app store. I expect their skills will be much in demand. In fact, I know they are.

The second group built a Ruby on Rails applications that interfaced with the Amazon and the Facebook API's and used mysql, jQuery and had other javascript niceties. Only one of the students had experience with Ruby on Rails, and none had used web APIs before. It was another large learning and doing experience.

Still, aside from the technical knowledge they acquired, what they always tell me they learned most is how to work in a team and coordinate their time so as to get large projects like these done. That is not something that can be learned in a lecture.

SeaPort Container Terminal Simulation

Next week I will be presenting our (with Nathan Huynh) paper on agent-based seaport container terminal simulation at the workshop on agents in traffic and transportation.

Basically, we used netlogo to build a simulation of a container seaport terminal, like the one you see on the photo. We focused only on the decision-making process of the cranes. Those large cranes you see have to pick up the containers and place them on the trucks as they arrive. Since the cranes are slow and there are many trucks the crane operators have to trade-off several competing interests when making their decision: trucks want to get out of there as quickly as possible, it takes the crane a long time to travel the length of the seaport, the port manager wants to maximize the number of trucks served but without making any one truck wait too long.

In this paper we tried the more obvious utility functions to see how they performed in a seaport with 2 or 3 cranes. The utility functions used are:

1. distance-based: roughly, go to the nearest truck, but avoid getting on the way of the other cranes,
2. time-based: roughly, serve the trucks on a first-come first-serve based, while trying to stay out of the way of other cranes,
3. a mixture of the above two.

Test results showed that the distance-based won, by a lot. It won not only on the throughput, as it obviously would, but also on the fairness measures, which is not so obvious.

I'll be putting up the netlogo model on my MAS Netlogo models page soon. The slides from the talk I'll deliver on Tuesday are below:

We are currently working on expanding this model, both from a programming, simulate more parts of the supply chain, and the analysis side, put some bounds on the solution quality that can be achieved assuming local control and local information.

What We Should Teach IT Students

Yesterday I attended POSSCON where I saw a talk by Andy Lester on "What We Should Teach IT Students". As the use of the word IT in the title reveals, the target audience for the talk was enterprise developers.

For readers new to the field, enterprise developer is just a type of job. The easiest way to define the term is by pointing out that Blue Cross Blue Shield and Bank of America hire "enterprise developers" while Google, Microsoft, and Valve hire "software engineers". That is, enterprise developers write the software that makes the business run smoothly—process insurance claims—while developers write the software that IS the business—the new version of Windows. From an accounting point of view, enterprise developers are often a cost center for the company while developers are a profit center.

Still, the recommendations are largely applicable to all. He recommends students learn:

1. Source control
2. Bug tracking
3. Compiler (paying attention to the error messages)
4. Make and the philosophy of repeatability
5. Lint / splint or similar static code analyzers
6. Serious editing
7. DRY: Don't Repeat Yourself
8. Defensive programming
9. Maintenance: working on other people's code
10. Manual testing
11. Automated testing
12. Efficiency and why it does not matter
13. Thinking about the: business, project, release, deadline (getting the bigger picture)
14. Teamwork: work well with others

Our curriculum covers all of these, some more than others, and I am in full agreement with all of them.

Some of these, however, I think must be left mostly to the student. I know that learning to use the editor is super important, but I don't think we need an actual class to teach editing! I really can't see myself standing in front of our students for a whole semester telling them "To compile your code, press F8; to indent your code press Ctrl-A then Crtl-I". They know they can just get the list of shortcuts and memorize the ones they need. Still, I do make a point in my classes to stop and explain how I got System.out.println to appear after just typing sysout. Similarly, learning to use a source control or bug tracking system is just not that hard (compared with, say, implementing a compiler). Overall, the students who have not learned to use their editor, or understand compiler errors, or DRY, are generally the few who really don't care about programming, and their grades show it.

Still, I agree that these are all important skills to have.

Andy also said all students should have read Code Complete, which is the required textbook for my 492 class. He also mentioned The Pragmatic Programmer which is also a personal favorite of mine and on my list of recommended books for 492. Of course, we all know they are good because stackoverflow says they are.

Multiagent Systems Introduction

Last week it was my pleasure to give an invited talk at Temple University, part of their Robert M. and Mary Haythornthwaite Foundation Distinguished Lecture Series. I tried to provide a high-level overview of multiagent systems is all about, which is always a huge challenge as the field covers a lot of disparate areas. After some thought, I decided to pick three applications and

1. describe all the issues relevant to the problem,
2. show how we use theory (either algorithms, game theory, or Economics) to get a better understanding of the underlying issues,
3. explain how there is still much engineering that needs to be done because even the best theory or algorithm still millions of details, and software is just a collection of details.

For posterity sake, below are the slides I used. The slides contain as little text as possible, which I think generally makes for a better talk.

Learning Java Videos

Last semester I taught CSCE 145, our introduction to Java programming class. For that class I created a set of videos that teach the basics of Java programming using Eclipse as an IDE. The videos were very popular with students, especially those really new to programming. So, if you are a student interested in learning to program, go check them out.

CSCE 145: Chapter 1: Introduction to Java from Jose Vidal on Vimeo.

Current Research Talk

This Friday at 2:30pm in 300 S. Main B102 I will be given an informal talk about our current research projects for our CSCE 791 class. This is open to anyone else who is interested. It will be a long rambling and highly disorganized version of my previous 7 minute talk.

Ongoing Research Projects

Every year our department has 7-minute madness presentations in which we faculty present our ongoing research. It is a great opportunity to hear about all the innovative research going on in our department (especially in the area of multiagent systems, of course :-). The slides from my 7-minute talk are below.

For those of you who could not make it, and since I ran out of time after just a couple of slides, I write a bit about each project below.

We have a lot of papers published on distributed combinatorial auctions, especially on bidding algorithms for the PAUSE auction. This work was done with Benito Mendoza who received his PhD in May and is now working at Exxon on multiagent simulations. I continue to work on this topic but with a slightly different focus: viewing these distributed auctions as negotiation networks.

The iCoach project is with prof. Sara Wilcox from the department of exercise science. Chuck Burris, and undergraduate, has been developing on the Google App Engine a webapp that will send customized SMS messages to users by first gathering information from the user's phone, pedometer, and online information (where he is, via GPS, how much he has moved, via pedomenter or accelerometer, what his plans are, via his google calendar, etc.). There is a lot of information about us on the net, and the new smartphones will give us even more. However, aside from collecting and displaying this information back to the user in a pretty graph, there has been very little research done in to how to use this information to improve our lives. That is what we study. Our initial system is being designed to monitor, educate, and coach first-time pregnant women.

The wikitheoria is another Google App Engine webapp we are building, and by "we" I mean Jon Mayhak and Jason Rikard. The project is with prof. Barry Markovsky from the Sociology department and can be summarized as "wikepdia meets stackoverflow for sociologists, with added semantic structure". Our goal is to build a site that will enable and encourage sociologists to post their models using a common ontology (set of terms with agreed-upon definitions). The common ontology will also be developed on the site. The current site is currently being tested by forcing a graduate class of sociologists to use it.

The port simulation project is very new and its joint work with prof. Nathan Huynh from the department of Civil Engineering. Nathan is an expert in ports and trucking problems. In our initial collaboration we are looking at the problem of how the crane operators in a port should act or cooperate. The job of a crane operator is to pick up those big containers, one at a time, and put them on the trucks as the trucks arrive. The containers can be stacked up so sometimes the crane operators have to do some re-stacking of the containers, which wastes a lot of time. We are building an agent-based simulation of this problem and trying to find best strategies for the operators.

Andrew Smith is a new PhD student who has already written a paper on supply chain resiliency. Using standard models of supply-chain formation we generated sample chains and then tested these topologies for resiliency to single-point attacks. That is, if one node goes down how does that affect the network as a whole. In the paper (not yet published) we present a numerical measure of resiliency and our test results show how it varies given the number of relationship resources (a measure of sociability) and size.

Andrew is also continuing his work with Karim Mahrous from Sandia National Labs on media dispersion and influence as part of his PhD thesis. This is another agent-based modeling project, albeit a much larger one for which we only have to develop small parts of the code, which aims to model how news travels in a social network. The project will cover everything from broadcast media, to multicast media (twitter), to one-on-one via electronic (SMS) or good ol fashioned conversations over lunch.

So, if you are a graduate student and find these ideas interesting, you can sign up for my Multiagent Systems class in the Spring which will cover the basic background knowledge needed to build, and understand, multiagent systems. If you are from a funding agency or company with a few bucks to spare for research, I would love to hear from you!

Capstone Projects

A blog post by Joel Spolsky on Capstone projects complains about how many of the top CS departments do not teach their students how to write large programs or how to work in large teams. Perhaps.

Here at the University of South Carolina, I created our CSCE 492 back in 2000 to address these problems. 492 is our capstone software project whose main goals, as I see them, are to:

1. Give the students the experience of working in a large (100 pages of code or more) software project.
2. Give them the experience of working in a group.

Our 492 projects are definitely not the type of project that can be finished in one or two days. They are much more significant than that. Still, on my first few years teaching it I learned that students do tend to postpone work until the last month. Thus, I have established certain guidelines.

Each group has a weekly meeting with me. In these meetings they give me their progress report and I keep track of of how much has and has not been achieved. We also set priorities for the next few weeks. Lack of progress is duly reprimanded, as any manager would do.

At the midterm there is an integration demo. Modern programs include several number of third-party libraries, from web frameworks to 3D engines, depending on the type of program being built. Students tend to underestimate how long it will take to install apache, mysql, mod_perl, library-X, put it all into svn, and get all that mess of code to say "Hello world" reliably. The integration demo is a proof-of-concept milestone which assures all of us that yes, this can work. After the demo all that is left to do is add all the features.

Finally, there is the shared code repository (I use code.google.com). Not only is this a tool that all professionals use, but it also helps me keep track of what is really going on, or not going on, in the project. Of course, it also helps the group coordinate their activities, as it was designed to.

So, yes, capstone projects should be an integral part of every Computer department's required curriculum, if the department is interested in creating graduates who can write software.

Still, I have to admit, it takes a lot of time to manage, advise, and code review 3 to 5 different projects at the same time. That might be the reason other universities either don't do this or leave their students on their own.

All Applications will be Web Applications

I often mention this in my classes and other talks: it is clear that the majority of new applications will be web applications (not all of them, of course, that is just standard headline hyperbole).

Jeff Atwood gives some more reasons as to why this is happening. Basically, people like web applications because they don't have to install them or worry about what happens when they get a new computer, business like web applications because they don't have to worry about installing their custom software on every PC. We can see old desktop applications, Quicken, being replaced by web versions Mint which are better in many ways.

But the real draw of web applications lies in the interconnectedness they allow (see the photo above for an example). These applications are also services and provide REST API's for other applications to plug into them. In this way each application is also a programming library (remember DLL's and .so files?) and a database with up to date information. Thus, even the so-called desktop applications of the future will also be web applications in that they will suck down data from the web, like Google Earth. I am still trying to figure out what the proliferation of all these REST APIs and microformats will mean for multiagent systems, but I can't help but feel that this is good news for the field.

So, what does this mean for a new student? First of all, it is still programming. While you might be using a slightly higher-level language, you will still be writing for-loops, recursive functions, and lots of if-then statements. No one has invented a language that can eliminate those. Thus, nothing much changes. One still needs to have solid programming experience and knowledge of algorithms.

On the other hand, the architecture for web applications is different from the standard desktop. In a standard desktop application you write event handlers that run whenever the user clicks on a button. In web applications this becomes more complicated. You can write your JavaScript to handle events from the user, just like in a desktop application, but you also have to deal with the client-server communication (AJAX magic). This raises all sorts of very interesting questions about what activities should be handled in the server versus the client. For many of the current set of applications the decision seems easy (gmail) but it is not as clear for others: should mint.com generate their pie charts server-side or client-side? The decision depends on the user experience you are after as well as the capabilities of the client and server devices and the network that joins them (wired, wireless, reliable, spotty).

It is very exciting to realize that allowing others to use your software is as easy as emailing them the URL, and that they can use your software on their PC, netbook, smartphone, set-top box, kindle, etc. etc.