Jeff was excited by his new project. His company wanted to add an ASP.NET interface to the same database used by one of their Windows Forms applications. For this company, "application integration" meant that two programs looked at the same database. Any change to a database and every application using it had to be updated, individually.

Since Jeff's first day at the company, he had been frustrated by the lack of code reuse, and this was a text-book example of where code reuse should work. He could grab the Windows team's DAL and business layer, slap a web front end, get the project done in a fraction of the time allotted for it, and make sure future maintenance helped both applications. Optimistically, it could be a model for future applications in his company.

"No," Carl, the project lead for the Windows side of development said. Carl glared at him like Jeff had been bitten by a zombie and might turn at any moment. "Your web application is a different application, and I don't see why you want any of our code."

"It's the same application," Jeff protested. "We're accessing the same data, doing the same things with it. The only thing that's changed is how we show it to the user."

"I don't want to have to deal with any confusion," Carl said. "This isn't a simple application. We can't just do what you want. I guess I could give you the DAL framework we used to build our DAL, I suppose."

Over the course of the next week, the battle continued, in meetings, emails and conference calls. Carl, a twenty year veteran with the company, had more knowledge of the political terrain and out maneuvered Jeff. Jeff had to strike his colors and accept the framework objects Carl was offering. A little code re-use was better than none. But Carl came back with some extra rules.

"You can't put your DAL classes in the same project as the Windows ones. And you should prefix all of your DAL classes with the word 'Web' so no one grabs the wrong code."

"Ignoring the fact that is idiotic," Jeff replied, "why would we do that? The UI and the DAL are completely separate. It doesn't matter how we present the data, the DAL is just fetching it."

The meeting didn't end in a fist-fight, but Jeff's manager had to step in and smooth over the roughed up egos. Carl's rules stood, as absurd as they seemed to Jeff. Jeff inspected the code Carl had provided. It had a rather unusual requirement for a DAL: the caller had to pass in a Windows.Forms.Form object, along with a ProgressBar and a StatusBar. Jeff read through the code and found the DAL framework updated the ProgressBar and StatusBar while it waited for results from the database.

Jeff emailed Carl an apology: "I withdraw my comments about the DAL and the UI being separate concerns. I was apparently mistaken." No sanely developed ASP.NET app would have access to Windows Forms objects. For the umpteenth time in his tenure, he re-invented the wheel and wrote his own DAL and business layer. In the end, Jeff was probably better off for it. The first rule of code reuse is that the code needs to be worth re-using.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!