Software engineering vs. Computer Science

There is a difference between Software engineering and Computer Science.  Just like there is a difference between Mechanical Engineering and Physics.  I believe that the big difference is that in the physical world, people have been building structures for thousands of years.  The difference between the theory of the physical world and the building of things in it is well defined.  Modern computing has been around for what, 60 years?  We have not yet defined the difference between the theory of Computing and the practical application of it.

In computer science, the task is often to find the best, or most efficient way to perform a task.  Often, Computer Scientists are looking for theoretical limits, or trying to resolve a new computing issue in a novel way.  


In software engineering, you are trying to build a system to meet a need using the tools at hand, given the constraints of your system.  Often this means NOT using the best solution.  It means using the best solution given the constraints placed on your use case.  
As a Software Engineer, this means we do not necessarily build things on our own.  Rather, we evaluate alternatives and select the best one.  One example of this might be Web Frameworks.  Another might be ORM selection (or whether to use either of these technologies at all and actually build our own).   This is analogous to a mechanical engineer designing a car - he doesn't also design the tires, alternator, battery, etc.  Rather he looks at the alternative possibilities and selects the best one for the vehicle he is trying to create.  Of course, there are going to be many areas that the mechanical engineer does build.  


It seems like in software engineering, using other peoples tools is frowned upon.  There is some sort of badge of honor to say, 'I built this myself'.  While it is impressive to have that broad range of skill, does that necessarily make you the best Software Engineer?  


It is my belief that as a profession, we Software Engineers need to start thinking of our task as more of an engineering endeavor and less of computer science endeavor.  We need to see ourselves not as Scientists, but as Engineers.  

Bug fix for Unit Test Generation Plugin

I fixed a few bugs in the Unit Test Generation Plugin.  I think the next release is going to be a re-factor only, as the code is pretty rough and I want to be able to keep this project clean.  I believe after a few more edits I will be comfortable declaring the project a 'Beta' project.

Get the latest download

Inversion of Control - Results

In a previous post I talked about how to identify and re-factor a section of code that had a switch statement in it.  I was finally able to get to that statement at work and re-factor it.  I thought the results would be interesting to post.

First and foremost, I was able to remove 120 unnecessary lines of code and replace it with 2 lines.  That's right, where once there were 120 lines there are now  2.

But there is more to the story than that.  As I mention before, I've been unit testing the application(and that led to a new Eclipse tool), so as I re-factored the system, I re-ran my tests.  At one point my tests FAILED.  That's right, I BROKE the intended functionality with a re-factor that shouldn't have.

When I looked into it further, I found that one little switch statement buried in that twenty-two case wonder didn't follow the pattern.  Instead of getting an implementation from the factory and calling a getMap method, it was calling an entirely different method in the main class.  After a little research and a few short lines of code, the issue was fixed and the tests once again showed a green bar.

The actual work here is not relevant, what is relevant is this:  This is a pre-release version of this system.  It is not even in Beta testing yet, and there is already a place in the code that was 'hacked' to work differently than you would expect.  The implementation of a pattern will help prevent this kind of degrading of the code in the future, but it was there.  In the code. Before the software was even released.

The second thing to take away from this:  If I hadn't written all those unit tests, I wouldn't have found the error.  I would have re-factored the code and introduced a bug into the system without realizing it.  Unit tests saved me.  And because of that, my company will now have a system that is more resistant to errors and less prone to new bugs.

A two week diversion. Eclipse Plugin to Generate Unit Tests

I took a new job about a month ago at an insurance company. The company is in the middle of rewriting the Point of Sale application for its line of business. Since the project had already kicked off and development had begun, I had been assigned the glorious task of filling in Unit test coverage.

You see, the management at this company is pretty new to Agile development methodologies, and until about a year ago, Unit tests were largely unknown to them. They are driving a tight timeline for delivering the rewritten project. Often, the developers are going over their burndown hours, so the first thing to suffer was, you guessed it, the unit tests. On top of that, management is insistent on getting 80% coverage. As you can probably guess from the title of this post, I was assigned the duty of creating unit tests for this iteration of the code, with the purpose of increasing code coverage to as close to 80% as possible.

When I was handed the code, the coverage, depending on sub-project, was between 0% and 20% covered.

I decided to create an Eclipse plugin to help me with the task (On my own time, of course.  During the day, I wrote tests.) I call it Unit Test Generation Plugin.  This version is very basic.  It really only works to create tests for POJOs at this point, but I think I'll extend it a bit to make it more useful soon.

I was really quite surprised at how easy and fun it was to create a plugin for Eclipse.   I thought I'd post some of the code and the process I used to create the plugin on the site.

Here are some highlights.  Let me know if you'd like me to write more detail about a particular topic.

Binding An Event To The Eclipse Package Menu
Eclipse uses a powerful plugin framework to allow you to extend and enhance the platform.  The way to add extensions is to use the PDE, which is a part of the core project.  Eclipse makes creating a new project VERY easy.  To start, go to File->New->Project...->Plugin Project.

In the New Plugin Window, Enter a name, like com.a.plugin.  The rest of the defaults can be left alone.  Click, Next.  Another popup appears to allow you to select more options for your project config.  Modify the name and provider all you like, but the defaults should suffice.  Click Next.

The final panel allows you to select several templates that demonstrate different extensions.  You can select a template if you like, or none at all.  For this project, I will select none.

When you finish, a new Eclipse plugin project is created and you are ready to continue.

Extension Points
An extension point is how you add new functionality to Eclipse.  They are configured using an XML file.  Eclipse supplies an editor to allow you to easily edit this file.  I had some trouble configuring my Handler through this screen, but was able to write the code by hand.  Once I edited it, it appeared correctly in the editor.  I've done a little reading and that might be because I didn't have some RCP plugins installed, but I haven't verified it yet.

Java Code Support
It also turns out that Eclipse has robust support for Java project Elements.  There are interfaces like ICompilationUnit, IPackageFragment and so forth.  It was pretty easy to generate new tests.

The Result
I have decided that I am going to make the project open-source and created a SourceForge project for it.  It is still in Alpha stage, and there is a bit of work to make it a 'real' plugin, but its now out there in the world.

Unit Test Generation Plugin

Now, I'm sure that Robert Martin would hunt me down if he knew what I created, and would destroy the laptop it was written on (OK, I don't really know him, but I've read one of his books, Agile Software Development, Principles, Patterns, and Practices.  From the perspectives presented there, I can infer that he would not be happy with my tool