A date for this event is yet to be announced, but if you would like to get your vote in early for things you would like to see covered, do let us know.  And spread the word.

Title of Presentation
OSGi in Anger

Brief Synopsis
Telecom Web Services is an application framework that enables the creation of SOAP and RESTful applications over telecom capabilities such as SMS, MMS, Location, etc.

Starting off life as a single monolithic project, the system has evolved into a highly modular product made up of many OSGi bundles and a design that relies heavily on OSGi services to support core infrastructure and to enable OCP-style extensibility.

With 10000+ unit tests, TWS is a fairly large and complex system, but thanks mostly to OSGi it has managed to maintain its design integrity and yet remain relatively cheap and easy to work with and extend.

However, developing with OSGi has not been without its own share of pain, and in this talk Tara will discuss how these issues were overcome as well as how its many great features were put to effective use, and how they helped solve many problems:

• The virtues of enforced modularity (on a large project)
• Working with OSGi services and how services were used to underpin many design decisions
• Wiring & Spring DM
• Working through the pain barrier - Hibernate, build, perceptions of complexity,…
• Testing
• Lessons learned

More information can be found at the SQC Ireland conference website.

Apparently the companies that came out of America’s Great Depression best were the ones that spent on marketing and advertising.  Even in tough times, companies can grow and prosper.  Our belief is that even in today’s tougher world, there is way more software to be written than there are people capable of writing it.

That’s partly why we are growing.  The other reason is that no matter how good or bad the times are, we see a real need for a software company at the top end of the market - one renowned for its excellence.   Growing is essentially validation of that primary goal.

So welcome, Marty Henderson. Marty joins Instil with 8 years of broad industry experience, bringing with him a raft of Java, JEE and .NET experience.  His first job is helping a valued customer develop and deliver their Java Portal for release early next year.   More importantly he will be working on a number of product-related ideas in the background.

This is stuff that has been written about a thousand times, and much of it is now part of mainstream developer culture (well, almost). Some of the points will even seem a little dated. But like trawling through long forgotten photographs, it can be interesting to see were you’ve come from.

I should point out that this was written in 2004/2005, not long after reading Mary Poppendieck’s Lean Software Development - thus the frequent references. It was also written with reference to a particular customer’s setup. Not every organisation is the same, so some might disagree with these points or perhaps find that I didn’t go far enough (it was half-completed afterall), but I do think most of the points hold true today regardless.

1. Foster a culture of technical excellence:
* Make training a priority. Allocate a training budget, and make sure it is spent. Work closely with developers, their mentors and tech leads to ensure that training needs are met. At the same time ensure that training is appropriate to the needs of the individual and the company (i.e. spend the budget wisely).

*Encourage staff to purchase technical books and literature (and make it easy to do so). A book purchasing scheme is not only an excellent and affordable way to train staff, it is also highly motivating: Staff consider it as a perk. Developers should be free to buy books on all aspects of software engineering; requirements elicitation, testing, process, design, etc. Create a recommended reading list on the company WIKI.

*Encourage and reward certification. Be prepared to fund certification training, time-off and the actual exam(s).

*Conferences. Every developer should go to at least one, and come back inspired

2. Ensure all developers are grounded in key software engineering skills
* Educate staff on requirements elicitation techniques: breadth before depth, use casing, user stories, prototypes, etc.

* Educate staff on testing and testing techniques: Boundary testing, equivalence classes, unit testing, acceptance testing, etc.

* Ensure developers are grounded in OO design principals and methods: Open-Closed principle, DRY, design by contract, test-driven development, refactoring, single responsibility principle, simplicity, etc.

3. Make quality a cornerstone of all activities
* Introduce code reviews: Define a simple, effective code review process. Reviewing is not just about catching defects early (although this is their primary purpose), it’s about shared learning and applied consistency.

* Introduce (automated) developer testing. Make developers accountable (see empowerment). The culture of ‘I think it works, so I’ll throw it over the wall and see what happens’ should be replaced with ‘I know it works because I’ve tested it and have the automated tests to prove it’.
- Ensure that developers understand the difference between unit testing (building the code right) and acceptance testing (building the right code).
- Ensure developers understand the significance of TDD as a design methodology. For product development to be truly cost effective, the concept of sufficient design should be understood and adopted by all.

* Introduce continuous integration (CI): CI tools such as CruiseControl will, when used as an integral part of the development process, reduce development cost. Defects are fixed when introduced, not when found 3 months later during manual testing. CI is an essential ingredient for any software project.

* Introduce ‘nag-ware’: Use freely available tools to inform developers when standards have been broken, OO coupling is bound too tightly, etc.

4. Define and implement programming guidelines
* Define exception handling guidelines: Developers should understand the difference between checked and unchecked exceptions. They should also, by and large, avoid the use of checked exceptions– they complicate code and the overall programming model, particularly with large scale applications. (Note that Java is the only language to use checked exceptions.)

* Define logging guidelines: Moreover, don’t write entry and exit diagnostics: Use AspectJ to weave standard entry and exit logging rules into source code. Not only is code clean and quicker to write, but logging is more consistent since one aspect/approach exists for the entire application. (Logging is a cross-cutting concern, i.e. something that applies to most packages, classes and methods and as such be removed from all modules.)

* Define Javadoc guidelines: Javadoc, and to a lesser extent unit tests, should be used to document intent. Developers should understand how to document using Javadoc. Documenting at the package, class and method level encourages developers to reason about their code. Javadoc should be published via standard tools, e.g. Maven.

* Re-define style guidelines: Remove superfluous commentary requirements from source – it is simply noise, is time-consuming to maintain, is difficult to read and is mostly unnecessary. Also, more generally, define when and how to comment code. Insist that source code contains no hard tabs (so that it can be viewed in multiple editors). Insist on explicit imports. Go with convention - use either Sun’s or Eclipse’s formatting rules.

* Allow guidelines to be adaptive: Guidelines are not written in stone and should change with the times. Guidelines that are found not to work should be simply removed altogether.

5. Create Slack for All Development Staff
* All Developers, but especially technical design authorities, should be given the time and space to learn. The implication being that time invested now will be time saved in the future. Slack is about being given time to look above the parapet, to investigate new technologies, tools, techniques and methods with the goal of improving productivity, quality and lower costs.

* Free technical leads to mentor and guide the team. Don’t assume that every team member understands your vision – people will go off in their own direction if not otherwise instructed. Some will go off even when instructed. Most developers, particularly graduates, need to undergo an apprenticeship – mentors and technical leads should be free to facilitate this. (See nag-ware.)

6. Avoid doing things that can be done with tools
* Use AOP to weave in logging, security, etc. Never write that which can be automated. Never repeat cross-cutting concerns at the beginning and end of each and every method, e.g. entry and exit diagnostics, security, transaction demarcation, policies, etc. Use Spring.

* Use Maven to publish test results, javadoc, Checkstyle/PMD reports, change logs, Subversion source cross-references, etc. Maven provides excellent visibility into the current state, and therefore health, of a system.

7. Empower developers (but make them accountable)
* See Mary Poppendieck’s Lean Software Development.

* Adopt test driven development (TDD) as a standard development/design methodology. Developer tests improve confidence, trust and quality. Tests drive design. Tests provide visibility into a systems health. Tests tell you how far you need to bring a design (is it sufficient?). Developer testing should be placed firmly at the centre of every developer’s working practices. (If you can’t test it, then you can’t code it.)

8. Communicate regularly but informally (whenever possible)
* Use a WIKI. Encourage developers to use the WIKI on a regular basis. The WIKI should be viewed as the main portal for all informal but informative information. It should be used to publish standards, processes, and titbits of information – indeed almost anything. Appoint a wiki administrator whose job it is to organise the information on the WIKI so that it is easy to find, intuitive and consistent. (Note that the WIKI is not home for formal documentation.)

* Be agile: Have SCRUM meetings, use information radiators, etc

You can almost guess where this customer was when these points were written. And I certainly could have gone on. The good news is that they have since totally re-invented their developer culture for the better. But I do wonder how many firms lack any discernible developer culture - one that fosters excellence at all levels? Experience tells me that most developers are just too busy doing stuff, with their heads down below the parapet, unable or unwilling to create time to do things better.

I had no idea what Rod was going to talk about, but having spent the past year developing an OSGi and Spring DM based application framework, I thought it would make an interesting diversion to talk about this rather than your usual Spring and JEE enterprise application .   Interestingly, immediately after my own presentation, Rod proceeded to enthuse about this hugely powerful combination, essentially validating a lot of choices we made way back when Spring DM was still in beta.

Little did we know at the time that Spring Source would be announcing their own OSGi and Spring DM based application platform only a matter of weeks later.  The hints were there in the keynote, but no more than that. 

I should point out that there is little cross-over in Spring’s offering and the framework that we have been working on - they are 2 completely different beasts.  In upcoming posts, I intend talking a little more about this framework and about the many technical humps that had to be overcome in its development.

The course will cover everything from programming fundamentals (with Java), testing, tools, web application development, databases (and SQL), building, configuration management (and SVN), use-casing, prototyping, and the software lifecycle. Delegates will also get a chance to create a mini-application from the ground up, using their newly acquired knowledge, with the instructor acting as the customer.

This is one of a number of induction courses that we have supplied to Liberty IT over the years, and thankfully they continue to be extremely pleased with the value and quality of our training. But there is no doubting the ambitiousness of this course - taking a group of newbies and converting them into solid engineers over 3 intensive weeks is a huge challenge, but a challenge that we are extremely excited about!

Looking ahead, we will continue to combine our joint design and programming expertise in future work. Needless to say, if you like this site and would like to have your own updated, then feel free to work through us.

As an fyi, this site is a mixture of static content (.htm files) and dynamic content, driven through Wordpress.

Please free to get in touch with us if there is anything you feel we can do to improve what Momentum does