Like most schools, Andy’s requried a “capstone” project for their software engineering track. It was a group project, which meant the project’s success was largely dependent on the luck of the draw. For his partners, Andy drew Mindy and Al. Mindy, he knew from other classes and had worked with before.
Al was a stranger, but Al had made his presence known from the very first day of class. You see, Al had industry experience. Al had been working with a global manufacturing company for a few years, and didn’t really need this class. He lived this stuff. He knew more than the professor, so Al spent most of his time trying to help the other students, even going so far as to hold is own informal “office hours” in one of the computer labs. At their first team meeting in one of the conference rooms in the library, Al explained, “This project here looks pretty close to some of the work I’ve been doing.”
“You’ve implemented a database for a library to track users and assets?”
“Not exactly,” Al said, “but it’s a basic data-driven application. I’ve written thousands of these.”
“That’s really great to hear,” Andy said, “because Mindy and I haven’t actually taken the databases class yet- we don’t really know SQL.”
“Great!” Al said. “I can work on the data-layer.”
As an experienced enterprise developer, Al took the weekend to write up a specification for the database layer, which he gave to Andy and Mindy. They could use a stubbed version of the database layer, while Al did all the work on that side.
“Now,” Al warned as they reviewed the latest ER diagrams in a quiet corner of the campus coffee shop, “I’ve worked on a lot of projects like this, so let me warn you- we’ll probably need to spend some time doing some serious integration testing to link all of these modules together.”
“Oh, I’d expect as much,” Andy said. “If you can finish your work within the next week, we’ll have two weeks left to do our testing.”
“Will do,” Al said.
Al didn’t do. He didn’t get his database layer committed until one week before the due date. He skipped the next team meeting and sent an email, “Project crunch at work, not available. Will send updates.”
Andy and Mindy fired the application up with a pile of instructor-provided test data. It took nearly 100 seconds to filter through the 1000 test users and find a single user’s account. Performance got worse with larger data-sets, like the list of books in their “library”.
If it were just poor performance, Andy would have thrown indexes at the problem and hoped that cleared things up. There were worse problems, though. For example, according to the database, today’s date was “Martha Sawyer”. User “Jim Mahony” had $–155132 in late fees, there were 15,005.542 books in the database, and 16,000 of them were available to be checked out to users.
Andy decided to take a look and see if he could address those bugs. He immediately regretted the decision, because one look at the code told him that he had just given up on getting any sleep for the next week. Al did okay at managing database connections, but his “vast” industry experience apparently didn’t include the use of the “where” clause. Every single query he wrote followed the pattern:
SELECT * FROM `table`
Al always loaded the results into a 2-d array. If Al needed to filter, he passed the matrix into a linear search. If Al needed to sort, he passed the matrix into a bubble sort.
Andy didn’t really have any choice. He threw out Al’s work and reimplemented the database layer from scratch. At their final meeting before turning the project in, Andy diplomatically explained, “I had to make some changes to your code.”
“Oh, sure,” Al said. “I know there were a few bugs in there. It’s not like you’re my parter in the Digital Electronics class- the day before our logic circuit project was due, he ripped out all of the wiring I’d done on the bread-board and did it from scratch. That guy was a real jerk.”
“Well… actually… ”