Thursday, April 28, 2011

Master of Software Engineering

Finally, I am an MSE. That's, Master of Software Engineering. I just finished presenting my capstone project at Carroll University.

A lot of people don't know what Software Engineering is. Is it related to Development? Is it really an Engineering discipline? I'd like to take this time to talk a little bit about what I think a Software Engineer is.

Let's start with the official definition of 'Software Engineer'. Any search these days starts with Wikipedia, and in fact, Wikipedia has a nice listing for 'Software Engineering', with lots of references. Here is the first paragraph:

Software engineering (SE) is a profession dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build. It is a "systematic approach to the analysis, design, assessment, implementation, test, maintenance and re-engineering of a software by applying engineering to the software".[1] The term software engineering first appeared in the 1968 NATO Software Engineering Conference, and was meant to provoke thought regarding the perceived "software crisis" at the time.[2][3] Since the field is still relatively young compared to its sister fields of engineering, there is still much debate around what software engineering actually is, and if it conforms to the classical definition of engineering.[4] The IEEE Computer Society's Software Engineering Body of Knowledge defines "software engineering" as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.[5] It is the application of Engineering to software because it integrates significant mathematics, computer science and practices whose origins are in Engineering.[6]
Wikipedia, Dec 24, 2010

If I were to put that rather lengthy description into my own short words, it would be: Software Engineering is a way to build better software by studying and applying a systematic, disciplined and quantifiable approach to the development process.

You see, to me, the key characteristic is that while Software Engineering includes software development, it really goes beyond just writing code or applications.  It is the study and practice of the processes that will make writing applications better.  Better may not mean faster or cheaper but will always mean higher quality. Although, sometimes, it will mean faster and cheaper, but usually in the long run.  So Software Engineering really expands into all the different tasks surrounding a system - business definition, requirements gathering, analysis, design, testing, and support.  A Software engineer should know about all these phases in the life cycle and should be involved with all of them.

But developing software is not exactly akin to designing a bridge or a car.  There's still a component of craftsmanship or artistry involved with software development. Methodologies can be used to improve estimates, quality, and outcomes, but there is also a large component that is more akin to writing a novel or creating a movie than to building a bridge or designing a car.

It is in that part of the software development process where the art of development presents itself.  Writing software is a creative and abstract task with many different ways to solve a problem.  In some cases, a single, best, solution can be found, but in so many others, there isn't one.  In that regard, some developers are artists, some developers really aren’t, and never will be. The rest of us are aspiring to be one of the great ones. We are competent technicians, writing our works, but not gifted with the ability to produce masterpieces.  Here is where what we learn and the techniques we apply from Software Engineering Study allow us to produce pieces of software that are in fact, solid and elegant.  We won't be writing the next Mona Lisa, but by following proper techniques, using the best practices, studying what works, and applying them consistently and rigorously, we can produce consistent, appealing work with high levels of quality.  If we work hard, people might one day also recognize us as an artist.

Perhaps not a Michelangelo, but maybe a Bob Ross.

Sunday, April 24, 2011

My First Scala App

I've been looking at learning another development language for some time. Over the years I've dabbled in PHP, Groovy, and even C/C++. While I learned a lot in doing this, I never became an 'expert' in any of them. For the most part, I used them for the project in which they were needed or for the scenario where they were most appropriate and then went back to Java for my primary development platform.

The reason is that I'd become so familiar with the Java tool set, language, and available libraries. I was (and am) most productive in that environment. But Java is showing its age and limitations. Its becoming clear that some of the most vexing problems facing developers will need a full range of tools to solve them, and while Java's OO support is good, its functional support is not. I, therefore, decided that I needed to expand and really learn another language pretty well. I decided that language is going to be Scala.

Why Scala? Well, I'll go over that in a different post. This post is about my experience writing my first Scala app. So, here it goes.

The Application
Since I am changing jobs (again), I decided I would leave something behind for my co-workers.  In our current work environment, we have a shared drive where server error logs are stored in 'pseudo' XML format.  It was always annoying to me that we had to navigate the file structure, open a text file, and hunt through the file to find an error we would be looking for.  It was also difficult to determine how often an error was occurring.  Now, the easy way to solve this is to use the log4j XML appender and read the files with Apache Chainsaw, but this is a large company, and it decided to go with a proprietary format.  I decided to use Scala to write a little desktop app that the developers could use to view the log files in a tabular format, then select a row to see the stacktrace detail.

The Functionality
The application needed 3 essential things : a table to show rows, a TextArea to show the detail, and a FileChooser to select which log to view.  In the background it also needed the following processing capabilities:  read in a file, modify the text to make it valid XML, parse the XML tags.  That's about it.

The Results
Well, I whipped out the app pretty quickly.  It would have been much more quickly if I hadn't been learning Scala along the way.  There were some really nice things about Scala that I found out.  First, its swing wrapper classes are nice, and their pub/sub model is succinct.  Second, the XML processing is excellent.  The built in support for XML files allowed me to parse the logs in a couple of lines of code.  Finally, the Actor metaphor for multi threading was also very easy to use and implement.

I had a few frustrations along the way as well.  The Eclipse plugin was nice, but it still doesn't have code-complete (One of the biggest productivity tools in my mind).  The code-complete is supposed to be in the plugin, but for some reason, doesn't seem to work for me.  I've tried on 3 separate computers. This meant that I was reading a lot of documentation.  Its also hard to read the documentation.  Since Scala has so much support for so many features, the docs can get a little complicated to read.  I'm sure as I become more familiar with the libraries and syntax this will get easier, but I can see how it would be daunting for a junior developer.

Conclusion 
I'm by no means a Scala expert at this point, but I enjoyed the language enough, and it seems to have enough benefits that I'm looking forward to learning more.  Who knows, maybe one day Scala will be my primary language...