Mark McConachie

The Importance of Saying No

2011-07-06T00:00:00Z

The past few weeks have highlighted an important lesson learned for me. During the development process, it is easy for both the client and the development team to just keep saying yes!

We need to focus on ensuring that we carefully choose what we say yes to as this can have major effects on project deadlines, budgets and the final product.

When we don’t say no

As a Project progresses, it is natural for the requirements to evolve. Using agile development we do all we can to manage this from iteration to iteration, however this is not always easy.

There is a difference between evolving scope and evolving requirements.

When new requirements evolve it is very important that we assess whether this fits within the scope and how it could effect the projects deadlines and budget.

Most software developers care about customer service, I certainly do.

This makes it too easy for us to say, “Yes, you can have what ever you want”. When we do this we are not always considering the consequences for the project. We need to assess whether this is a change in scope or a evolving requirement.

When a client doesn’t say no

Most designers and developers who I know are passionate about their work. When we build something we really get into it, we get excited about it and lose a little bit of our critical analysis of what we are working on. This is normal.

When we then present this work to a client, this enthusiasm can change the perspective of the client too. Causing them to see the work in the same light as we do and not to analyse whether it meets their needs.

This is another problem because when the client says ‘yes’ this changes the path of the project away from what they wished for.

Near the end of the project there will come a time when you all step back and see what you have achieved.

This is when this problem can be highlighted, when the projects deadlines are close and the budget is running out.

The bottom line

It is our responsibility as designers and developers to avoid these mistakes. We need to learn that saying no is not always bad customer service and that changes in direction should always come from the client.

Getting Started with Agile Development

2011-03-11T00:00:00Z

Agile development is a popular project management methodology for small software development teams.

Working at OpenFinder we have found that people don’t always know what to expect when working in this way for the first time. In this post I aim to explain the basic principles and how they effect someone working alongside an Agile team.

This post is not designed to teach you how to be an Agile developer, however it should make life a little easier when you start working alongside an Agile team for the first time.

Release early, release often

Agile development’s main focus is on frequent delivery of a product. Time will be divided into small time boxes (often between 1 and 4 weeks), referred to as iterations. The team will deliver a product at the end of each of these iterations.

Releases are small increments on top of the previous product

The traditional development lifecycle follows the process Analyze ➙ Design ➙ Develop ➙ Test ➙ Release.

These methodologies are often refereed to as BRUF (Big Requirements Up Front). The focus here is on gathering all the requirements at the start of the project and testing and releasing the whole product at once at the end.

It is usual for requirements to evolve during a project. At the start of each iteration, an Agile team will check for any requirements which have evolved since the last iteration.

Using an Agile methodology often produces a different product than was visioned at the start of the project, however it will produce a product that fits the evolving requirements better.

Timescale is fixed

Always adding requirements has the potential to make the development time for the project grow and grow. Agile developers counter this by setting the project in a fixed timescale.

At the start of each iteration, requirements are prioritized and the most important functionality is included as early as possible. This means that when the final release date is reached, the released product includes the most important functionality that fits the timescale (and your budget).

User Involvement

A big difference between Agile development and traditional methodologies is the focus on user involvement.

It may not always practical to have users directly involved with the development and in this case the team would work closely with someone who would represent these users.

Having user representation is imperative to identifying emerging and evolving requirements while also ensuring that the prioritization of requirements accurately represents the views of the end users and/or customers.

The relationship between developers and the user’s representative is close. The representative becomes a member of the team as valuable as any of the developers.

Team Work

This will be the biggest change for you while working along side an Agile team. Agile teams tend to have a large focus on communicating with you, including you in their team and working together to build you the best product that fits your needs and your budget.

Sinatra powered contact form

2011-03-09T00:00:00Z

I wanted to design my website to be as minimal as possible. To start with I didn’t even include a contact form! I just had an email link.

I realized that I needed a page with my contact details and realized that this was the perfect place for a contact form.

A few weeks ago, I integrated Sinatra and Toto to work together. Both the new contact page and the processing of the form are handled by Sinatra (with help from pony).

Soon I will enhance this page using jQuery.

What enhancements do you feel a contact page requires?

Seven Languages in Seven Weeks

2011-03-08T00:00:00Z

Recently I have been feeling the thirst for new software development knowledge. I want to become more familiar with the programming language types which I am less familiar with.

Last week, I bought Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages by Bruce A. Tate from The Pragmatic Bookshelf.

The book covers the following languages

Ruby
Io
Prolog
Scala
Erlang
Clojure
Haskell

So far, I have read the Introduction and plan to get the Ruby chapter wrapped up pretty quickly. Each chapter is divided into 3 area’s, each designed to be tackled in a day. With my experience of Ruby, I am going to attempt this whole chapter in an evening.

I am going to write a short post about each chapter and new language as I get through them over the next 7 weeks!

What do you do when you feel the thirst for new knowledge?

Toto Powered!

2011-02-10T00:00:00Z

Hello and welcome to my new website

I have been experimenting with various blog and content management systems recently and started to get really sick of how heavy most of them are.

Next, I decided to build my own blog engine. First using Ruby on Rails, which was great, I am familiar with Rails and development went fast. But then I stopped and looked at what I had created and realized that I was also creating another overweight CMS.

I decided to downsize, being a ruby programmer Sinatra was the obvious choice. I started hacking away at a lovely little git powered site and I was pretty happy with it.

This was going to be the platform on which I would run this site!

But one day, I came across this TINY blog engine called Toto. Toto is build straight on rack, no Rails, no Sinatra, no bloat. After looking through the source code, I loved it. I know that this little blog/CMS engine was simple and I like that.