We’re in the business of bringing new ideas to life. It is our responsibility—our commitment to our clients—to exceed their expectations. As we all know, this mandate never comes without a price.

There are numerous, glorious (and even more inglorious) battles to fight against technical obstacles, internal/external resistance and, sometimes, even against the customer.

If you feel driven to exceed customer expectations and develop yourself as a software wizard, join us in our quest.

Leonidas develops software that matters. Our customers are industry-leading multinationals and startups positioned to create substantial value for their own customers using IT solutions. Our core competence lies in understanding the value-creation mechanisms of our customers. We create superior solutions by exploiting years of experience in agile methodologies, alongside technical excellence and business acumen. Our operations concentrate on Web and mobile domains and technologies.

Interested? Let’s see how you can become a part of our team.

Passion rules the game. As I have met people from different walks of life—be it teachers, software developers or architects— I have found one thing those making a difference have in common: passion. It’s that drive—that inner urge to create something new or improve something old. When you have it, there’s nothing that can stop you.

We’re looking for people with passion.

Understanding is essential. Let me clarify this a bit: You need to be able to understand what those things are that create value for the customer. I know they didn’t teach you that in school—they taught you how to write code. Well, in our world, writing code is not enough. Every developer makes hundreds of decisions every day. Some of them are major; some are minor; but every single decision is potentially meaningful. In order to make good decisions, the developer has to be able to understand the context and the dynamics of value creation.

We’re looking for people who understand.

Knowledge of preferred technologies and experience, however, do give you an edge in the interview. Currently, we’re looking for developers who are familiar with Ruby on Rails, Java and mobile frameworks. Now, if you have 3-5 years (or more) of relevant work experience accompanied with references and a spectacular track record, let us know you exist.

We’re primarily looking for people with relevant work experience.

The next step? Just send me an open application, and we’ll see how it goes. :)

Some tips:

- There are a million places that describe how to make an impression during the job interview. Check out at least one of those.

- Rehearse what you’re going to say…  before you come to the interview.

- Bring a piece of code with you, and prepare to explain what you have done.

Nature of Software Quality

Software quality is still one of the great challenges in the industry. Due to the inherent and unique nature of computer programs, there are no universally accepted methods for ensuring apparent program quality and even fewer practical methods for program verification. However, both of these are not only very important, but also are related. Furthermore, final product quality takes much more than ensuring good source code quality: there is the user interface and overall user experience, documentation, etc. Quality has to permeate the whole project, not just the software and implicit byproducts. There is requirement analysis, customer communication, project management, support. Customers are not seeking quality software tools for their problems—what they really want is quality solutions to their problems. That aside, my scope here is limited to the source code quality.

Curiously enough, many professional developers seem to be able to distinguish intuitively between a poorly written program and a quality one. Yet most tools capable of producing comparable, numeric values somehow denoting a specific, qualitative aspect of source code are frowned upon. This is not because such tools are useless; the problem is that it takes more than a glance at the final aggregated figure(s) to really benefit from them. In particular, static source code analysis takes you only so far. Many important aspects in the source code do not deal with syntax but with semantics, something of which our computers are blissfully ignorant.

The Principle

I have often pondered a question that an apprentice programmer might pose: What is the single most important thing I should learn to become a Good Programmer? Recently, I think I have found the answer. It is the principle known as Separation of Concerns (SoC). It seems that I am not alone. To put it loosely, SoC means that a module, class, function, or method in a computer program should deal with only one thing, with no functional overlap with others. It is closely tied to the concept of loose coupling, and is considered so important that most programming paradigms aim to help developers achieve SoC.

All design patterns separate the specific composition of objects and functionality as a whole (the pattern) from the objects’ individual, domain-specific functionality. Procedural programming helps achieve SoC by separating concerns into procedures, whereas object-oriented programming uses objects for the very same purpose. The famous MVC pattern is based on the very core idea of SoC by separating the actual logic (model) from the user interface (view and controller). Functional programming allows complex composition of functions irrespective of function arguments, thus separating actual data structures from program flow. Splitting methods to smaller pieces by level of abstraction is applying SoC.

Many other ideas derive from or result in SoC as a direct consequence, such as “A class should have one and only one reason to change.”

Impact on software

The benefits of SoC are numerous. First of all, it helps us understand any given computation unit (module, class, method or function) because it deals with only one “thing.” Second, it makes encapsulation and hiding easier, as a change in one unit usually does not require changes in other units. Third, it makes automated testing much easier, as both the state set-up for the test and testing the outcome are simple: given this input, expect this output (or state change, but not both). As such, SoC is one of the core tools in managing software complexity. [1]

What about performance and reusability? Because SoC leads to indirection and due to extra instantiation and chained method calls, performance does suffer a bit, at least in principle. But the benefits far outweigh the incurred costs, as it allows for very aggressive local optimization without fear of breaking other parts of the system. Increased orthogonality and tightly restricted functionality lead to more reusable components as well.

However, sometimes applying SoC is very difficult. There might be pervasive features such as logging and security that are used throughout the project. Maintaining loose coupling and avoiding repetition could amount to anything between trivial design issues to very difficult ones, depending on the language and/or supporting libraries. For example, the Ruby language makes it relatively simple to, say, decorate certain types of calls with custom callbacks without modifying the source code of affected computation units. This is because Ruby has very powerful metaprogramming facilities such as dynamic method definition, re-openable as well as executable class definitions and method introspection. On the other hand, programs written in Java usually require AOP-style extensions such as AspectJ to achieve similar results, adding extraneous dependencies and new syntax to learn.

The point is that if SoC is so crucial, then surely the programming language should help the developer in achieving it, even coerce the developer to that direction. On the next part, we’ll see what kind of programming language would be ideal from this point of view.

References

[1] http://www.cs.au.dk/~eernst/papers/splat03.pdf

Lesson #11: Review the project.

Process is best improved by those who do the actual work. Our project team gathers for a retrospective the day after the prototype is delivered — while we still have the ideas and problems fresh on our minds. We discuss things that went well, things we could do better, and what actions we are going to take to improve the process.

For learning how to organize good retrospectives, I recommend the awesome book Agile Retrospectives by Esther Derby and Diana Larsen.

Lesson #12: Update your process.

We keep our process documentation as light as possible. Currently, our entire process is described with a one-page how-to and a checklist. To inject our improving understanding into our process, we update these documents after each retrospective.

We also use how-tos that describe the most important technical tasks, such as setting up a new web application to our production server. These guides help us avoid stupid mistakes, and they save time when a team member does the task for the first time.

Lesson #13: Share what you learned.

Rapid prototyping gives us feedback in seven days. When we get positive experiences, we share our findings with the rest of the company. We use wiki, Google Wave, and Leonidas hour to spread information within the company. To share our experience with the world, we write blog posts such as this.

Lesson #14: Enjoy the results.

Everybody loves getting feedback on their work. When our sales team returns from the demo shop, they share the customer reaction with us developers. Having worked hard for seven days, we find that it’s great to hear that the client said the results were awesome.

I hope that this journey in rapid prototyping gave you something to use in your own work. If you have any questions, please feel free to leave a comment.

If you’re interested in agile development, I gave a presentation last week in Demola; the material is available on SlideShare.

By the way, we have a post coming on software quality written by Edvard Majakari, who recently joined our company. Ed is a great guy, and he’s always there to help when it comes to making better software.

In our seven-day process the first day is spent with the customer in a start shop. The next five days are dedicated to development, and the last day is reserved for the demo shop where the prototype is handed over to the customer. During the five-day development sprint we develop, test and deploy the prototype in iterations. Let’s go through the lessons we have learned in this process.

Lesson #6: Spend time on design.

Rapid prototyping is a combination of craftsmanship and cowboy coding. Usually cowboys take over when the deadline is closing in. To keep things professional throughout the project you should spend time on design. It has a few benefits:

• Working out challenging use cases and problems in the beginning will reduce chances of failing.
• When there are more developers involved in the project, the design helps to divide the work.
• The product owner can verify the key requirements against the design.

In our projects, we have drawn the initial data model and layout designs on the whiteboard. The design usually changes during the development, so we rather spend our time developing than updating design documents.
Make it quick and keep it simple. The purpose of design is just to keep all the cowboys riding in the same direction.

Lesson #7: Deploy early and often.

Applications tend to work differently in production than they do in the developer’s computer. Verify that your prototype is working on the target device or in the production server as early as possible. Once the first deployment is made, you can start testing the prototype.

Deploying often is possible with automated deployment tools. Capistrano works great on Rails projects. Mobile applications can be installed from the IDE (e.g. Carbide, Aptana Studio) with a few clicks. When the deadline approaches and the going gets tough, automated deployment will save you from errors.

Lesson #8: Prioritize and estimate the task backlog continuously.

The task backlog is for managing the development tasks. It states which tasks are the most important ones and how long they will approximately take to implement. The backlog visualizes the remaining work and it helps us decide which tasks we should focus on.

We use a shared spreadsheet as task backlog. Everybody can add a task: the product owner, developers and testers. Every task that requires at least 15 minutes is listed in the backlog. Tasks longer than 4 hours are divided into smaller tasks to keep the estimates as accurate as possible. The developers give their estimates and the product owner decides the prioritization. With this information and a pinch of common sense we decide what to do next.

The beauty of the task backlog is the continuous evaluation. If a task requires more time or a new feature arises, we estimate it and we see immediately how it affects our schedule. Then we drop some unimportant items or simplify the implementation. So rather than sticking to a plan we continuously evaluate our situation and make new plans. Quoting Eisenhower: plans are nothing; planning is everything.

Lesson #9: Delegate tasks.

Prototyping team consists of different roles. In a short project it’s recommended that people concentrate on the things they do best. The developers should be busy coding. The test staff should be busy testing the application.

When we first started prototyping, developers were responsible for content creation. Then the product owner got more involved in the process since he has the vision how the prototype should look like. Finally we moved the whole content creation to the product owner. This solution resulted in more appealing content and gave us more time for development.

Lesson #10: Talk, talk, talk.

Instant feedback, quick decisions and information sharing require good communication. During development we have everybody working in the same space, so we can speak and hold ad hoc meetings (5-10 minutes) as needed. By talking a lot with the product owner we avoid a lot of misunderstandings and save development time by doing the right things the right way.

On the other hand, we also reserve time for silence. When we need to concentrate on our work we use the 45-15 rule. It means that for 45 minutes speaking is prohibited and then we take 15 minutes to discuss about the issues or problems we encountered.

Free breakfast and rapid prototyping

The last post of this series focuses on process improvement issues and the post will be published next week.

On Thursday Feb 18 Leonidas and Codento are organising a breakfast event on rapid prototyping and cloud services. The event begins at 8:00 in Scandic Tampere. Participation is free of charge but please register online (registering also available through Facebook). Welcome!

But what if we change the rules a little bit. What if you have to deliver in seven days within a budget, the prototype must work and you need to do this every two weeks. Can prototyping still be fun?

Since spring 2009 we have been working with mobile and web prototypes here in Leonidas. In our case rapid prototyping means a fixed price seven day software project. Two days are reserved for understanding the customer’s needs, designing the prototype and holding the start/demo shops. Five days are dedicated for development.

Over the next few weeks I will be writing a series of posts of the lessons we have learned. This first post is about preparation. The difference between rapid prototyping and a traditional software project is the very strict deadline. Rapid prototyping is like the Cooper test: run as far as possible within 12 minutes. Those runners who have prepared well run the longest. For developers good preparation equals more features done.

Lesson #1: Understand the project goal

The customer has ordered the prototype for a reason. Usually they need a prototype to show to their organization or to their own customers. Or their developers are busy working and they need somebody to build them a walking skeleton for the next project.

Understanding the customer’s needs helps us develop the prototype. If the prototype is used for demos, the visual stuff is more important than the robust form validation we could spend hours working on. So instead of coding everything, you can describe functionality with pictures and enhance the user experience with AJAX.

If the customer needs a walking skeleton, you can spend more time on making your code readable and documenting how the prototype can be developed further.

As the bottom line, understanding the goal helps you to decide where to focus your efforts.

Lesson #2: Prepare yourself for the technical challenges.

Time is our most important asset and we need to spend it carefully. During the development phase it’s better to spend time on customer’s needs rather than learning Rails’ nested forms.

Try to get as much details as possible about the project before it begins. We usually get some information from our customer before the start shop, so there’s time to think about the implementation. If there’s an unfamiliar technical area, there’s still time to study it before the project.

Lesson #3: Check your development environment.

Installing the SDK, configuring the demo server or matching your tools with your co-worker’s environment are issues that require only a little time if everything goes smoothly. If something goes wrong and you use more hours to solve the problem, you have spent a part of your most valuable asset.

It’s better to be ready before the project starts. Create the code repository, create user groups, configure the demo server, prepare the project wiki. Doing these beforehand can save you a half day’s work.

Lesson #4: Have your project management tools ready.

In our prototyping projects we need to handle requirements and test results. The concept designers have an ongoing discussion with the developers how the prototype should work. These requirements are written to the task backlog with priority and developer’s time estimation. Whenever testers find bugs they also write down their findings to the backlog. Developers pick tasks based on the priorization and mark them done when finished.

We use a shared spreadsheet as our task backlog. It’s fast, easy to use and developed for our needs. After trying some online project management tools and a task board we decided to stick with the spreadsheet since it worked best for us. The backlog spreadsheet is improved between projects and that would be quite impossible if we used a commercial tool.

The lesson here is to have the backlog or any other tools you are using ready before the project starts. Make sure the tool is really helping your team.

Lesson #5: Find reusable code.

If you make a list of the common functionality web applications have, you would list things like authentication, authorization and lost password mailers. From prototyping view these are nice-to-have items (see Lesson #1), so you shouldn’t waste time on them. But on the other hand, you would impress your customer by delivering these features.

One solution is to have these features available in your project skeleton (check out Ryan Bates’ excellent Railscast). Knowing the features are tested and ready to go, you can concentrate on the items your customer really needs. In Rails projects you can also use gems and plugins to get a flying start. To avoid risks, try the gems/plugins before the project.

Hope you enjoyed this post. Next week I’ll be posting about the lessons we’ve learned in the development phase.

A couple of examples will illustrate this.

Consider ERP: The bottom line promise of an ERP system is that it will manage all the business information of an enterprise. When this is done, the silo effect (at least with regard to data) is done away with and single functions and units need no longer be islands of information. Decisions can be made, not just based on local information of functions or units, because data for the whole enterprise is available for every unit. Local optimization is no longer necessary. For example, marketing can coordinate pricing campaigns based partly on current inventories in the supply chain and manufacturing resources that are currently lying idle. Centralized data also provides a top-down view of the enterprise. The flipside of this scenario is that local optimization needs to actually stop in order to realize the full benefits of an ERP. If decisions are made based on the old rules, gains will be significantly diminished.

In a wider enterprise system context, the right kind of IT architecture will enable the propagation of best practices and process improvements much more quickly than “traditional” means would permit. Business processes can be analyzed, improved, brought under statistical control, and, finally, replicated and propagated inside the enterprise. For example, a forecasting model, bundled with a forecasting process can be built in one unit or geography, tweaked to high performance, and then copied to other units in the same company. This kind of ability is also a major argument for uniform architecture across the whole enterprise. The magnitude of potential benefits was elaborated, for example, by McAfee and Brynjolfsson in their 2008 Harvard Business Review article Investing in the IT That Makes a Competitive Difference. They show that the ability to manipulate and propagate business processes with IT systems has a strong link to overall competitiveness.

In both examples, the user friendliness of the home screen in any given software application is not pivotal. And, in both examples, the real heavy duty gains to be had from an enterprise system lie first and foremost in the enterprise, not in the system. The ability of systems to change the way real world processes function is often at the essence.

Further material:

McAfee and Brynjolfsson, Harvard Business Review 2008: Investing in the IT That Makes a Competitive Difference

Eliyahu Goldratt 2005: Beyond the Goal: Eliyahu Goldratt Speaks on the Theory of Constraints

The answer: prototype to validate the idea as early as possible.

Even a harsh, simple, ugly and defective prototype is better than no prototype at all. It clarifies the concept in three important aspects:

1) Do the product champion and the implementors share a common vision?

2) Does the product address a real customer need?

3) Can the concept be realized using current technology?

Expensive – and unfortunately common – mishaps occur if these concerns are not addressed properly.

First of all, if the product champion is not able to clearly communicate his/her vision to the implementing party, the direction of the development might be wrong from the start. The earlier this is noticed, the cheaper it is to fix.

Secondly, even the best visionaries get it wrong most times.

It is important to get feedback from the potential customers/users as early as possible. A good prototype is something you can show to the customer and ask “would this solve your problem?”

And thirdly, as the implementors get to inspect, evaluate and execute the concept, they form a better understanding of its technical requirements. For example, they may find out that implementing the project would be extremely expensive. ROI on this kind of insight will naturally be substantial.

So, when you’re pondering upon the Next Big Thing, actualize it as fast as possible. You will be greatly enhancing the time you can use on the right ideas.

The problem with this is that the feedback received at the top is distorted by misinterpretation at each level. False premises lead to bad decisions and frustration at all levels. The organization may never realize how much more they could do if they understood each other and made the right decisions.

At Leonidas we are set to reverse this. One of our tools is the “Leonidas hour”, a weekly one-hour meeting that anyone can attend to. Here’s how it works.

• Before the meeting, anyone can suggest a topic.
• At the beginning of the meeting, everyone who suggested a topic briefly introduces it.
• We select the topic by consensus or – if there’s none – by voting. Then we discuss that topic.
• The goal of the discussion is to make a decision. Sometimes there’s not enough information or not enough time for that. That is all right – it is better to make no decision at all than to make a bad one. But there should be a genuine attempt to solve the problem, not just hot air.
• If there’s time after the first topic, we tackle the next topic, and so on.

The idea is to have everyone at the same place at the same time so that decisions can be made quickly. Since everyone is there, and everyone can question any idea, people will leave the meeting with an understanding of the “why” of the decisions as well as the “what”.

Of course, the effectiveness of Leonidas hour relies on people’s ability to discuss things effectively. It requires trust, candor and willingness to improve – which happen to be the values of Leonidas. As long as we follow those and give ourselves time to make good decisions, we should do well.

So how are we doing? We’ve had four Leonidas hours so far. The topics were

• new office: furniture, who sits where, etc. (twice)
• this blog: themes, posting schedule, topics (twice)
• our Protosonni service: what can we do to improve it
• communication tools: how should we use Google Wave, email, wiki
• Leonidas hour: how can we improve it

So far our experiences have been mostly positive. There’s a feeling that we all can contribute, and that we make better decisions.

Probably the most difficult problem we noticed was with the schedule. Since we are working on different projects, it is hard to find a weekly time that suits everyone – and the one we found tends to interrupt the most productive work time. Another thing we would like to improve is focusing on decision-making. The discussions advanced more slowly than we anticipated. It may be a matter of preparation.

To address these issues, starting from January, we are going to replace weekly Leonidas hours with longer ones every two weeks. We will also prepare topics better. If a topic doesn’t have an initial suggested solution, it is not ready to be discussed. We use Wave to prepare the topics: if someone has a topic but doesn’t have an idea for a solution, he can write a wave and hope that someone else comes up with a solution. Or if anyone has objections to a suggested solution, he can raise them in Wave. The theory is that this will enable better discussion during the actual Leonidas hour – we will see how that works.

We will certainly keep making changes to the concept as we get more experienced with it. Maybe at some point we will drop Leonidas hour altogether and replace it with something different. The point is not any specific technique, but making good decisions and improving continuously.

Ps. The location is optimal as there is a fantastic Indian restaurant nearby called Nanda Devi!