Developing good software takes time and much thought. It’s brain work. Building complex applications well is difficult to do at the best of times, but I imagine it would virtually impossible say in the middle of a busy shopping centre or on a construction site. Noise and much activity create concentration breaking distractions. A quiet room is most conducive to developing software well.

We encourage a quiet office environment for our software engineers. We’ve separated the noisy management/support/sales types from the quiet area reserved for hard-working software engineers and I find it refreshing to walk into a respectfully quiet room of people ‘hard at work’.

But wait, I can see that it is not as quiet as it used to be. It sounds quiet but I can SEE that it’s not so quiet. 20 applications open. Popup messages showing new incoming mail mail. Three simultaneous conversations in instant messaging. Banner ads flashing. How can you concentrate with all that quiet noise?

If you are a software engineer with 20 applications running on your desktop including email and instant messaging, I offer you the sixty minute challenge the next time you have a software problem to solve.

Here’s the challenge:
Move to a clean desktop with no email, no instant messaging, no ‘latest news’, no programming buddy, no mp3; just you and your IDE. Put a ‘do not disturb’ sign on the side of your desk. For one hour focus all your concentration on the problem at hand.

If you take the challenge I’d be interested in your observations, so post a comment afterwards.

One of the key values here at Applepie is simplicity. As a member of Applepie I strive whenever possible to deliver lean, readable, manageable code that meets its requirements and is a pleasure for other developers to use. It’s not easy. To help ‘keep it simple’ we follow a number of practices, such as code peer reviews, which at there heart have the question: “Is this simple?”. The outcome of these practices leads to better code that we have qualified as manageable and elegant. Code we feel is simple.

However, Qualifying or feeling something to be simple is often not enough, we want hard fact, we want to quantify how well a body of code exhibits simplicity. One answer, is to analyse the code base and generate metrics that can support us in our quest to simplify. One of the best metric I’ve found for this is Cyclomatic Complexity.

Cyclomatic Complexity (CC) measures the complexity of your code by counting the number of paths through your code. The number of paths is the CC number. The bigger the CC number the more likely that code is difficult to conceptualize and also less likely you can unit test that code effectively. It’s a bit like navigating a road, a Y junction fine, a cross roads OK, a four-way interchange is (well for me anyway) reaching my cognitive limit.

As a rule of thumb, Cyclomatic Complexity Numbers are as follows:

• Simple - 11 or less is optimal
• Manageable - 11-21, may be problematic and will require large unit tests.
• Complex - 21-50 will be problematic and certainly will not be easy to test.
• Forget it - 50+ cannot be tested and requires self-actualized yogi chess grandmaster to understand.

So how to profile your code for CC. I’m going to focus on Java though similar tools exist for C#, PHP, Ruby, Python. The tool I’ve used for Java is PMD (works with the IDE of your choice). PMD generates many static metrics on your code base including Cyclomatic Complexity.

To install PMD follow the instructions on this PMD onJava article, or if you only have 5 minutes here’s a quick install guide for eclipse. Pop the exploded zip downloaded from PMD into your plugins folder. After you have installed the plugin you need to activate the metrics for your project. Go to the project properties and select the Metrics option and then select the enable metrics. That’s it! The metrics are then calculated and a metric view is presented.

McCabe Cyclomatic Complexity (CC) is the PMD metric we are interested in. PMD generates these CC statistics for the entire project. It allows you to drill down a tree of statistics and quickly ascertain the highest CC for each package, class and method. It even highlights items over a threshold in red (defaults to11, but is configurable). Now at last I have the CC count for every piece of code I work on.

These generated statistics gives a great overview of where code needs to be simplified and (hopefully) helps a bit more in answering “Is this simple?”, allowing me to back up my gut feel with some quantifiable statistics.

If you want to know more on Cyclomatic Complexity see here. If your interested in other metrics supporting simplicity see Operands on an operation.

I was asked yesterday by a software engineer how to decide what task to tackle next on a project. I was happy to hear the question; it told me that the developer taking ownership and responsibility for the project.

The general principle I like to follow in setting priority is this: do first what is important and easy, do last what is unimportant and difficult.

Here’s how to determine the priority of the tasks to be done:

1. Write down the lists of tasks
2. Rate the relative importance of each task using a number between 1 and 5 (1=important)
3. Rate the relative difficulty of each task using a number between 1 and 5 (1=easy)
4. Calculate priority as importance multiplied by difficulty

The calculation will give you low numbers for those tasks which are important and easy and high numbers for those which are unimportant and difficult. Tackle first the items with priority 1.

Back in the 80’s, the “olden days”, before I was a software guy I was a builder guy. I drove around in an rusty Ford econoline van with scaffolds and ladders on the roof; tools and materials in the back of the van, techniques in the back of the head. Tools and materials and techniques. Most jobs required all three, and like all tradesmen I accumulated some of each over the years. In those days I would arrive on a project ready to hit the ground running - I brought the basics with me.

Now with more than a decade of industrial software engineering behind me, I’m pelased with the collection of tools and techniques I carry with me. I don’t mean the phone and the laptop. I mean tools like putty and firefox and scite and cvs, mstsc, thunderbird, skype, gaim, open office, gimp, password safe, igal and vi to name a few.

The contents of the toolbox change over time. I no longer use cygwin and though emacs is still in there but doesn’t come out so often. Subversion is in there now, though I haven’t used it enough to make it my own.

Some tools are best not left behind. To any java project I always bring eclipse, ant and junit, and usually log4j.

Re-usable suitably-licensed open-source software components are a big part of my toolbox. Here are some of the most tried and trusted components that I have included in various java projects over the years and am happy to recommend:

• Logging: log4j (Notice I’m mentioning it for the second time)
• Working with xml: dom4j provides useful functionality.
• Text indexing: lucene is an extremely well done component.
• Templating: velocity is proven.
• Scheduling: quartz is very robust and reliable.
• Working with pdf: PDFbox is worthwhile. I’d like to try a using pdfbox with velocity sometime, for templating pdf documents.
• File identification: ffident provides mime type identification. I added some (what I thought were useful) new features which I sent to the author, but he doesn’t seem to have folded them in.
• Http requests: http client is reliable.
• Http file uploads: Commons file upload is helpful for handling files uploaded to your servlet or jsp page.
• cleaning up html: nekohtml is very useful if you want to take html pages from the wild and convert them to xml in order to run xpath expressions against them.
• Working with excel spreadsheets: poi is handy for reating and writing html.
• Charting: JFreeChart is very useful.
• Embedded sql: hsqldb is a useful sql database written in java which can be embedded into your application to run in-memory or persisting to the file system.
• Scripting: BeanShell, Rhino, and BSF if you can’t decide between them
• JNDI: Commons naming provides jndi setup for your application using tomcat 4 style configuration. (I don’t know why this is not more readily available, if you do, please let me know!)

Maybe some of these tools will be useful to you. If you have some more tried and trusted components for java applications, maybe post a comment.

When I moved from the West of Canada to the West of Ireland in the early 90’s I left most of the tools behind me, the saws and the ladders and the compressors and the welder. I still have my old hammer. I’m a bit rusty on some of the techniques, but I’ll probably never forget the how to dry a paint brush, taught to me by my mentor Lorenzo Quarenghi, son of Walter: after cleaning the brush in water or thinner (as appropriate), go outside wearing your old shoes or boots. With your heel on the ground and your toe pointing up, hold the handle of the brush and tap the metal edge on the top of your toe. The spray goes onto the ground and onto the sole of your shoe, the brush becomes clean and dry!

Galway is a hub of excitement this time of year. The Art’s Festival is in full tilt in Galway now, and next week the races begin. Something for everyone!

And some excitement brewing in the software development community as well! Today I went to Avaeon’s office near the race track where I had the privilege of a personal presentation of their newly released Topoix product, which provides a development framework and deployment model for forms based web applications. Wow! This is really a piece of software to pique the attention of IT Managers who want to better, stronger, faster development and deployment of .NET applications.

Topoix is a .NET based framework that provides a structure on which applications can be constructed and deployed. It encapsulates complex actions and presents the developer with simplified methods to perform then; this allows complex .NET applications to be developed without the developer requireing a full understanding of all the associated technical complexities. The main goal of Topoix is to reduce the time and effort involved in application development.

Unlike some other software components, Topoix is not simply a development tool or a deployment model. Rather it is an extension to the .NET framework with aspects covering both development and deployment in order to produce software which, when compared to standard .NET applications, is faster to develop, easier to maintain, and more highly available.

The development framework allows for a complete(!) separation of form design and business logic. Form validation rules are defined as metadata separately from the html forms to which they are applied. Unlike standard .NET applications, developers need not edit aspx pages. Instead they concentrate on the business logic of the application leaving it to the framework to apply this logic into the html forms which may have been provided by a separate design team.

The framework also provides a transactionable persistence model to bind the strongly typed form data with the SQL Server database. The application binds values to/from the database using the appropriate connection and the sql mappings provided by the developer.

But wait there’s more! The framework provides inherent support for referential integrity, allowing dropdown lists to be populated directly from the referenced tables. I was most impressed with the dynamic way the declarative business rules are applied. Using simple declarations, the developer can specify that a change to one field on a form can cause other fields to be required or hidden or pre-populated!

Two features are particularly interesting when deploying your topoix application: automatic versioning and distributed session managment.

Firstly the business rules encapsulated in metadata are automatically versioned. Updated versions can be released onto the production systems without first removing the previous versions. Without interrupting existing sessions, newer business rules can be rolled out. New sessions will receive the updated business rules while existing sessions will be able to complete using the older version of the rules.

Secondly the application framework is of particular value when deploying web applications into environments where there is zero tolerance for work flow interuuption. Topoix provides distributed session management such that if a node in the server farm goes down, the failover to another server is transparent with zero interruption to users, even those who were previously connected to the failed node.

Avaeon was established in 2001 and have a wealth of experience developing and deploying highly available web applications in regulated environments. Topoix has evolved over several years and the current product has been in production use for over a year, for applications available to literally thousands of online users. If you want to know more about it visit the website.

Congratulations and wishes best luck to Anthony and the team at Avaeon! I look forward to building an application with Topoix later this year.

RTE reported yesterday that there has been a doubling in IT job vacancies over the past two years. The report is based an IT survey by DCU which has been conducted in an ongoing basis since 2005.

According to the survey there are currently 17,400 IT job vacancies in Ireland; two years ago there were 8,000. With a continued shortfall in IT staff it looks like Ireland is a good place to come and live and work in IT. If you left Ireland in the 80’s or early 90’s to find work abroad maybe it’s still a good time to think about coming back?

The shortfall of IT skills had already been predicted in 2003 by the Expert Group on Future Skills Needs who reported at that time:

The ICT sector downturn has caused an excess of supply over demand for graduates, but the expected recovery in demand may lead to a shortage of graduates in the medium-term. Supply and demand are reasonably well balanced for computing degree graduates up to 2006. Thereafter, the analysis shows that demand is likely to overtake supply, and eventually exceed it by a substantial margin.

I expect that the the growing competition for talented software engineers will increasingly lead businesses to outsource and subcontract their software projects. Weighing against the benefits of outsourcing or subcontracting software projects, astute buiness managers will acknowledge that the overhead of recruiting and retaining skilled software engineers in-house often simply doesn’t make business sense; using the services of a trusted and reliable supplier does.

I also expect that the most talented and enthusiastic of young software engineers will increasingly choose to begin and continue their careers with companies who value software engineering as the core of their businesses. This is where they will find the most opportunity to do what they like best: use software to develop innovative and reliable solutions to business problems.

Our own company provides software consulting and development services and I was interested in collating a list of other indigenous Galway companies offering these services. To compile the list I started off at the ITAG website, and followed the links to the various companies. I excluded from the list any companies which appear to be either very small (fewer than 5 employees) or inactive (website not operating).

If your business is seeking in particular a Galway based software consulting partner, you may be interested in making contact with some or all of these firms:

Applepie Solutions: (Our company) Application development and software consulting
Storm Technology: .NET based enterprise applications development and systems integration
Traventec: Software for the travel industry and bespoke software services
Metalogic: IT Consulting, Software Development, Database Management, IT Managed Services
Genbase Solutions: Systems Integration, EBusiness Solutions, Management Reporting, Data Migration and Management
Avaeon Solutions: IT consulting and development services for the financial services industry
Vulcan Solutions: CRM and Enterprise Systems for Financial Service Companies, and software development

If you think your software consulting business should be listed but isn’t, please add it in a comment below.

During our daily lunchtime chat William raised the topic of Steve Yegge’s blog about ‘Good agile, Bad agile‘. William argued that although the article is highly entertaining and while some of the criticisms are valid, Steve didn’t really present alternatives.
There ensued some discussion about various software methodologies which we’d been exposed to the past decade. The methodologies mentioned included waterfall, agile, scrum, omt, xp and rational unified process. My partner Stephen suggested that in each case someone has come up with a few useful ideas and observations about methods of developing software, but as you can’t sell “a few useful ideas” they’d take these, surround them with a load of useless ideas and voila! a new methodology.

Hmmn… I wonder is it true.

Here are some of my observations after a decade of software development:

• Gathering requirements and writing them down is important.
• Mock-ups are useful to help elicit the customer requirements and to set expectations. They also make the development phase easier.
• Keeping a standard structure on the file system for the software source code is useful, likewise standard naming for packages and files.
• Automated build procedures are handy.
• Unit testing is indespensible.
• IDE’s and compilers are your friends. Google is too.
• Leaving comments in code is a kind thing to do.
• Junior developers can learn from senior developers.
• Revision control tools are indespensible.
• Refactoring is often helpful.
• Gathering requirements before the development phase is more efficient.
• Keeping a list of things to do makes it easier to get them done.
• Good project managers do it without interfering.
• Bug tracking systems are good things.
• Coffee breaks and lunch breaks should be mandatory.
• Working extra long hours doesn’t result in a long term benefit.
• A quiet work environment is more productive.
• Copy-and-paste is evil and sometimes irresistable.
• No matter what it is, somebody else has probably done it before.
• Microsoft is NOT evil.
• Senior developers can learn from junior developers.
• Linux is NOT evil.
• Open source is a gift.
• C runs faster than java or C#.
• perl -p -i.bak -e ’s/foo/bar/g’ is handy.
• User interfaces are of utmost importance.
• Someone else on the team might know the answer.
• Code reviews are often useful but expensive.
• Some things are better done where you can’t be easily interrupted.

Hmmn. Maybe I could write the Fuller Software Methodology… I wonder could I write it on a 4X6 card?