Monthly Archive for April, 2006

Metrics-based software engineering

For those out there that know of software engineering methodologies, I doubt you know of metrics-based development. That is understandable, it’s not something that we are really taught, in fact for me personally it’s something I made up just these last few months. I don’t claim that it is anything profound or earth-shattering (even to like-minded software geeks), it’s merely what it is: a way to develop software that puts emphasis on the improvement of certain code-level metrics.

Clearly, the ultimate program in this metrics-based methodology is an empty one. That is also clearly not a very good program, so I don’t propose that this methodology be the core development methodology. A better idea would be to use this as a ‘guiding light’, to get an idea of how a project is progressing over it’s development lifecycle.

To aid in this understanding, it is suggested that the metrics be run at least daily (which can be automated). Each day numerous calculations will then be made, resulting in plenty of graphs being generated dynamically every day.

On top of this, a number is calculated between 0.0 and 1.0 that states the ‘health’ of the project, as calculated by these metrics.

The metrics performed include:
* Unit testing (JUnit)
* Unit test coverage (Clover)
* Static source code analysis for code smells / antipatterns (PMD and CheckStyle)
* Source code dependency analysis (JDepend)

The real value in this methodology is in two key areas:
* The ability to get rapid feedback on the introduction of good or poor code.
* The ability to easily see improvements and deprovements of code quality in a visual manner.

Visually seeing change is far better than the old solution: reading 100′s of pages of automatically generated logs on a daily basis, assuming the code was being built daily. This is clearly impossible, and thus the ability to track project change at this detail is also impossible. Metrics-based software developments opens up this ability, in a very simple graphical way that anyone can understand (in fact, every graph explains the ideal direction for the values to go).

To make it clear, this exists: I am running this methodology as part of my research this year, and it improves visibility hugely.

What else can developers do to make their own lives easier?
Cheers,
Jonathan Giles

Software Plugins Part II

Got a good query from Carl in an earlier post, where he asks:

So considering “plug-ins” are fundamentally just modular design blocks and have user definable interfacing what processes are in place to preserve overall look-and-feel, and usablitilty. And to reduce the mass of configuable parameters. That is to say, Microsoft products have been winners for two decades because someone can sit down and use them (knowing that most of the fiddly unimportant bits are preset to something out-of-the-box usable) and that the human-interface will behave in a somewhat predictable pattern every time the package is used. How does this plug-in system preserve that advantage?

I thought that this was a good question, and so in an attempt to make it more visible, I will now reply to it here as well:

Hey Carl, great question. I’ll keep my thoughts quick as it’s 12:30 am and I’ve been up since 7:30am yesterday in a meeting.

Plugins can not enforce usability requirements or maintain consistent look and feels.

But, neither can non-plugin solutions: it takes a team development mentality that requires these areas to be considered.

A point to note is that in my world view of plugins, they are not apparent to users – the end result is a program entirely the same as any other program. In fact, it is the same to developers as any other program – it’s just that unimportant sub-plugin code is encapsulated such that it becomes invisible and the effective code base reduces to the base API (Seeing as everything else – the fluff – disappears).

Hope that answers your question.
Cheers,
Jonathan.

Work

I must be a bit of a broken record, but the work this semester so far has been amazingly time consuming. None of it hard, just time consuming. I haven’t had much spare time to put my feet up, and its really starting to catch up with me.

I’m looking forward to the end of next week, as that is the end of the first half of the semester. I think we get about two weeks break. Between now and then, I need to finish my Haskell assignment (20% of paper), finish my programming languages report (20% of same paper), write an analysis of the music industry wrt IT/IS (3% of a paper), write up a discussion of problems with the current version of research, draw up use cases to motivate its redevelopment, and give a 30 minute (plus questions) seminar on the Java Plugin Framework.

The joy of fourth year and not having many exams….I think I have one and a half exams this semester for my five papers.

Over the break at this point in time I only have (so far…) to do a report on some application, more of my research, and probably write a few more reports, and sleep.

Hopefully everyone else out there is having a better time!

If anyone wants to hook me up with an xbox 360 (and I’m looking at Paul), I’ll more than happily accept it ;) , simply for rest and procrastination purposes.

Jonathan.

About

Jonathan Giles is a 25 year old software engineer living in Thames, New Zealand. He holds a Bachelor of Engineering Honours in Software Engineering, a Masters of Science in Computer Science, and is a Sun certified Java programmer. Jonathan specialises in Java, Swing, JavaFX and Client-Server development.

He is currently a software engineer at Oracle in the JavaFX UI controls team. He also blogs over at the FX Experience blog. Obviously, the opinions expressed here are his own.

Contact

Email:   Here
NZ:   +64 211 089 038
US:   +1 408 372 8057
Twitter:   JonathanGiles
LinkedIn:   My Profile
Skype:   Skype Me