This article is part of the bigger series about my Software Engineering internship this summer. To read all the posts, simply visit the category archive.

Another week has passed and I haven’t been lazy. I wrote a lot – of text but non of it was code. During the first weeks of my project I realized how much writing is necessary. In the first week I thought about the requirements of the product and wrote them down. Now, after my project sponsor approved my requirements analysis I was finally able to start thinking about technologies. Which again meant a lot of conceptual work instead of actual code writing.

But let’s start at the beginning. During requirements analysis I categorized my requirements in mandatory and optional ones. Seems like a good idea, but as usual with every further discussions with my stakeholders and future used the part of the mandatory requirements kept growing while the optional ones shrunk together.

So a User management has been added. Localization is mandatory now as well. Both were first “nice to have”. So when I went into the second week I knew it was going to be a busy week. The second phase was all about “concept”.

Which included the following on the solution side:

• Architecture Overview
• User rights concept
• Quality Assurance
• Training concept
• Operational concept

But also the following points:

• Effort estimation
• Total costs
• Capital budgeting
• Project organization
• Project plan

That was  a lot to do in five days. I was especially worried about the effort estimation as I had to settle for some technologies I knew I’d never seen before.

Technology decisions

Each company has it’s own favourite application stack. My company is focused on software engineering with Java and Open Source technologies. It just seems logical that application – even when you’re at total liberty to chose from – are built on the same basis. My project sponsor already said at the beginning: “You can propose whatever technologies you want, but be assured that we want to take the product in maintenance afterwards with as little effort as possible. So nothing fancy.”

If this would have been a personal project I would have loved to try out stuff like Scala, Node.js. But not this time. I was prepared to face (*ugh* pun) some JavaServerFaces web application. I already borrowed a heavy book about it from a friend. But when the project sponsor told me to speak with one of our Senior Architects to help me with my technology decisions, I got something completely different.

I currently propose a small and straight-forward web application based on the Spring MVC module. But instead of JSP views, I’ll use plain HTML views with jQuery and Angular JS. This will look something like in the picture on the right.

I’ll explain the design a bit more detailed: The Model-view-controller (MVC) is a common used design for computer user interfaces. I’ve used it before with the Play framework for example. As usual Wikipedia does a good job in explaining it.

A bit more special in this case though is, that I’ll use two separate MVC designs: One of the server side and and one on the client side. This is made possible by Angular JS, a JavaScript library by Google which could be used stand-alone to build a web application. It is also based on the MVC design. It tries to address the problem, that HTML hasn’t been designed for dynamic content. It enables data-binding, client-side form validation and much more, while keep the code short, readable and elegant. Yeah, I’m quite excited about it, that’s why I sound like an ad.

The other technologies are jQuery to simplify client-side scripting and getting access to a a vast UI Component library. JSON to communicate between the client and the server. The Spring framework helps with the Inversion of Control (IoC), it’s web module and it’s security module. Finally when it comes to the model we have something probably nobody will have heard from it: mimacom Glume. Well to be honest, I can’t yet very well explain what this is, as I haven’t yet used it or read much documentation about it. All I can say, is that it’s a internal project of our company to simplify and enhance data manipulation and interaction with the model. You’ll certainly hear more about it in the future.

So all in all, why those technologies? Well my project got “promoted” to some kind of a pilot project, serving product evaluation. It might be, that the company is using these technologies more often in the future. I’m certainly more than happy! Those technologies provide me with something new, fresh and innovative while still building on principles I know very well.

Oh, and some further small technologies I plan to use and wouldn’t want to forget mentioning are:

• LESS for intelligent and dynamic CSS
• Mockito for stubbing of objects
• JExample to write awesome Unit tests

The tool chain

When it came to effort estimations I started playing around with those technologies. Nothing was completely new it it’s core, but in it’s implementation. I wanted to get a feeling for the technologies and had a simple goal: Set up a Hello World application with this stack. Well actually I think that wouldn’t have been that difficult if I hadn’t have underestimated the whole aspect of a new tool chain. For the first time in my life I came in contact with something like a build-tool (Apache Maven), a web server (Apache Tomcat), a new IDE (IntelliJ IDEA) and a new VCS (Apache SVN). To set all this stuff up (especially Maven) took me way longer than expected. That’s where the following tweet comes from:

Sometimes a "hello world" is the most awesome thing you read the whole morning

— Joel Krebs (@jomikr) June 20, 2012

I still feel very insecure about Maven, but I already learned quite a lot. For example:

• Jackson (a JSON processor) doesn’t treats a String as an Object (although requesting a JSON answer in the AJAX request it can not provide one if you’re simply answering with a String, but simple objects work).
• Debugging through the intestines of the Spring Framework is actual quite fun, but very time consuming.
• Sometimes a asterisk in the servlet mapping solves all your problems (if somebody has an insight on this one, feel free to speak to me).
• Git remains my first choice when it comes to Revision Control.

Yeah okay, let’s not delve into that. In the end everything worked together and I got my “Hello World”.

The financial side

With defined requirements and my first experiences in the technology stack I was able to estimate the user stories. Luckily I already broke the requirements down into simple user stories in the first week. When it came to estimations I followed some simple rules:

• The smallest unit for a user story is half a day (4 hours)
• Estimate like you know what you’re doing

The first point expresses the perspective of “rough estimations”. Some developers I talked to, would have even only allowed days as smallest unit. But when I added the stories back to the requirements I got only days anyway. The second point was my way of handling the huge bulk of uncertainty with the new technologies. But I rather reduce the velocity of the team when dealing with uncertainty than over-estimating all user stories. So whenever estimating a story I though about implementing it with technologies I knew very well.

So from the estimation it was easy to get to a number for the total costs. But it again became more interesting when I had to do investment calculations. Is this project worth all the troubles? The answer is certainly not definite and depends on several uncertain factors:

• How much do you gain from the higher effectiveness with the new tool?
• What is the opportunity interest rate for such kind of projects?
• How do you value the gain of knowledge and the product evaluation aspect?

I calculated the Present Value of the Project and the Internal Rate of Return and let’s just say you can even justify the project with all it’s costs as an simple internship on a financial basis. To be honest: I didn’t expect that. But my company isn’t just doing well-fare 😉

So that’s what I’m going to present to my project sponsor and then I’ll get the approval to kick of the design phase or not…