A Programming Poem

for i equals ten
i greater than minus one
i minus minus

Grovr Apps Support

If you're having any problems with a Grovr Nokia Store app, please email me on support@grovr.co.uk or leave a comment belwo and I'll get back to you as soon as I can.

Matt

Does knowing a specific programming language matter?

This post is mostly inspired by a suggestion Steve McConnell makes in Code Complete: "Don't program in a language, program into it" (emphasis mine).


The traditional method of recruiting software developers is to go "We are writing our program in C++ so we should get a guy who does C++". I imagine many recruiters and companies use keyword filters on CVs to filter out candidates who don't have experience in the particular language used on the job. The basic premise of this post though, is that this is not necessarily going to get you the best man for the job.


My main points are:

• The time needed to learn a new language is shorter than it was and isn't that long
• 3 years doing 3 different languages is a better sign of a good and keen programmer than 3 years of 1 language
• The overhead of learning a new language becomes a smaller proportion over time and is overridden by the extra productivity of a "better" employee
• If you've only hired say, Ruby developers and then stop doing Ruby you can be in trouble

I should be clear and say that given 2 near-identical programmers, one with experience in the language you are using and one without, I would choose the one with experience in the language, but rather the point I'm making is that you shouldn't be afraid to hire someone who looks like a better programmer but doesn't have direct experience in the language.


A collegaue of mine recently said that you can grasp the basics of a language in about a month and start being confident and expressive in about 3 months and I agree. After that roughly 3 month stage, you start seeing diminshing returns on learning more particulars of that language (perhaps an example of the Pareto principle). The time taken to learn a language has dropped over the years, thanks to the wealth of information available on the internet in tutorials, blog posts and places like StackOverflow, as well as the reduction in the costs of publishing meaning more people are able to produce books on specific programming languages.


A good basing in a variety of languages, of different styles (eg OO vs functional, static vs dynamic typing) and a willingness to learn something new (I still don't quite believe that some people who were interviewed for my current role didn't want to learn JavaScript, I mean why wouldn't you want to learn something new?) are I believe, a better base for a productive programmer than just having experience in 1 language but for more years. This brings me to another point made in Code Complete applicable across all langauges (not just programming ones), that the language you know can actually affect the thoughts you are able to think. Being able to say "I know we're meant to be writing this in Java but there's a really easy and elegant way of doing it in Haskell" is of more value in my opinion that just steaming in and writing a sound Java implementation of every problem you come across. Importantly, experience in a variety of langauges is also a good sign that you've got someone who's interested in software development and does stuff outside of work rather than someone who just rolled into a say, Java job out of uni and then stayed in Java because that's what they'd done before and have never done any programming outside of work and education.


Now obviously, someone who's experienced in a language is going to be quicker to start writing in it than someone who isn't but that initial overhead will become a small proportion over the course of a long term employment (and hopefully you're hiring the kind of people you want to keep for a long time). The 3 month timescale I suggested above is obviously up for debate, but the argument here is based on the assumption that multi-language programmer will turn out to be more productive than the single-language programmer and thus cancel out the overhead, however large it is.


My final point is that hiring language specific programmers can seriously backfire if you decide to stop using the language. Kevin Rose of Digg raised this point at LeWeb conference where he said about hiring PHP developers to build out the Digg site "you end up with lots of PHP developers, but at some point, PHP isn’t a problem anymore and you are stuck with all of those developers". This is especially relevant I would think for startups, whose business direction is not as fixed as large corporations and may decide to pivot from say web development to iOS development and therefore suddenly need to be able to program in a different language.


Now obviously there will be some jobs where in-depth knowledge of the specifics of a language are going to be extremely useful, for instance in performance or safety critical applications (though many performance problems are best solved at the architectural level and so aren't very language specific anyway) but I don't believe that the majority of jobs are like that. Also I'm particularly biased in this discussion because I was hired into my current role as a JavaScript developer with no experience of JavaScript.

Test-Driven Development Review

This post is a review of Test-Driven Development - By Example by Kent Beck

The book is organised into 3 parts. Firstly, Kent takes the reader through an example of using TDD to drive a simple few classes for dealing with money in different currencies, secondly, in a fun bit of meta-ness, he takes the reader through test-driving a unit testing framework from scratch, using the framework he is writing to test itself! The final chapter consists of a large number of patterns for TDD.

The book is written in a very casual, conversational style which makes for easy reading. There are a few times in the book where the author states that he cannot think of something or a better way "at the moment" though I would guess these were more a way of suggesting exercises for the reader than placeholders left over from the editorial process.

Some of the more interesting points I found in the book were:

• Eliminate duplication, including duplication in tests of things in the production code
• First make tests compile with stubs
• When writing a test, invent the interface you would like to have
• First make a test pass, then refactor bit by bit, keeping the test passing until the code is clean
• 2 ways to quickly get to "green" (tests passing) - Return constants and gradually replace with variables until you have real code - use the real implementation straight away
• Value Objects - represent a value, value never changes, operations return new value objects
• Letting a test of 1 function depend on another function working is an educated risk
• TDD cycle:
  1. Write a test
  2. Make it compile
  3. Run it to see that it fails
  4. Make it run
  5. Remove duplication (clean code)
• you can entertain a brief interruption but never interrupt an interruption ( use a to do list to stop forgetting things)
• "Sometimes you should just ask the computer" - make a change and run the tests
• Sometimes write tests not to test external functionality but to inform future readers
• After you've finished your todo list, review the code
• 3 A's of tests: Arrange - create objects, Act - invoke methods on them, Assert - check results are as expected
• If a test you write requires lots of changes to be made to pass, write smaller test cases and then reintroduce the big test
• Isolating tests from each other encourages orthogonality in your code
• Write the asserts in a test first and work backwards
• Try to avoid mirrored data, eg 2 / 2 won't notice if arguments are wrong way round
• First tests can be extremely simple but allow to decide where the function belongs and what inputs and outputs it should have step by step
• Leave a broken test case at the end of a session so that you have something to work on next time, which will get you back into the same frame of mind
• Abstract (ie return more than constants) only when you have 2 or more examples (tests)
• If the obvious implementation is really obvious then just use that but fall back to faking and triangulation if you get red bars
• Composite Object - treat collection of objects as if it were a single one of the objects
• Seeing more than one message sent to another object in a method is a smell
• "In TDD the tests are a means to an end - the end being code in which you have great confidence"
• Keep tests that exercise the same path through the code is they convey different information to the reader
• TDD leads to "just-enough" design

One of things I would recommend to do as was suggested by the author was to actually write the sample programs as you go through the book. This is because the book itself did not always provide an overview of all the classes at every stage and also because it's more normal for most people to look at code on a computer rather than in a book.

A point often made against TDD is that much time is spent writing test code as opposed to production code, and whilst the author believes that it is time well spent, he does also suggest that if you do start using TDD you should measure your productiveness so that you can see for yourself whether it works for you and your organisation.

In summary, the books serves as a very useful introduction to TDD and inspires in the reader the want to try it out. I would have liked to see more patterns about how to write code that is easy to test but that was not within the main aim of the book.

Link to buy the book at Amazon.com  

Peopleware Review

This post is a review of Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco and Timothy Lister

Peopleware is a book that I read with great expectation. It had been mentioned in other books and online review with high reverence so I was expecting much from it and it certainly delivered. A point to get out the way early on is that the book is really aimed at managers of programmers rather than programmers themselves but I still think it is a book that every programmer should read. The usefullness for programmers comes from a couple of things, firstly, that some of the points made can be applied to your home environment and projects and secondly it contains great ammunition for negotiating workplace practices and environment with your boss in the form of reasoned arguments and evidence from studies.

The book is written in a relaxed and casual style which makes for easy reading but doesn't stop the authors from bringing out dry statistics when required to prove a point. It covers a wide range of managerial topics, from building successful teams to setting up the most productive workplace environment.

I didn't end up making too many notes on the book, because of the irrelevence of some parts of the book to me in my current role, but the book will be a very useful reference to have on hand when negotiating about the workplace with managers. Some of the points I did find interesting and relevant enough to note down were:

• Failing projects are more often caused by sociological problems than technical ones
• Often projects spend too much time trying to get things done and not enough time asking if they should be done
• Most overtime tends to be followed with compensatory "undertime"
• "People under time pressure don't work better; they just work faster"
• People tie their self-esteem to the quality of a product, not the quantity
• Increased quality -> increased motivation -> increased productivity
• Parkinson's Law doesn't apply to work you enjoy ( and apparently the law was never backed up with any evidence in the first place)
• In a 1985 study, the most productive projects had no time estimate or schedule
• "The manager's function is not to make people work, but to make it possible for people to work"
• Music lessons creativity as they are both right side of the brain activities (evidence in study)
• The Hawthorne Effect: "people perform better when they're trying something new"#
• Think of a work team as a choir not as a football team

The point about developers (and likely people in general) tying their self-esteem to the quality of a project rather than the quantity is something I'll be trying to keep in mind at work. The quality required for maximum business value is often going to be less than the level a developer would be most proud of, so I'll have to remind myself of this when a manager wants to release a product when I would consider it too early. Though I'd be very happy if my manager took interest in the follow up point that better quality leads to better motivation leading to better productivity.

In conclusion, I don't think the average programmer will find too much of immediate practical use in Peopleware but I'd still recommend that they read it for the insights it provides into the workplace environment, it's usefulness as a negotiating tool with managers and in case they ever want to step into management. As with my review of Mastering the Requirements Process, this is the first book I've read on the subject, this time management, and so I don't have much to compare it to, but as a developer I feel that if a manger were to implement the suggestions of this book then I'd be a happier and more productive developer and in some cases the book contains the statistics from trials to back up this feeling.

Link to buy the book at Amazon.com

The Pragmatic Programmer Review

This post is a review of the book The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and Dave Thomas

It may be having read a number of similarly scoped books recently, or sitting next to someone who raves about this book but I didn't learn as much as I expected from this book. As mentioned, I don't actually think this is down to the book not being full of useful information and insights, becasue it is, but rather because the content overlaps with many other books (many of which were actually written after this book).

The Pragmatic Programmer has a very practical focus, most of the content concerns writing code from a  variety of perspectives, from architectural, through functions, down to line to line coding. The coverage is very solid and feels quite complete in it's covering of many areas, though as the Authors say themselves they don't go into deep detail in every area.

The things I found most interesting or new from the book were:

• The DRY principle not only refers to functions but also to pieces of knowledge or assumptions. You should only have to change 1 thing if these change.
• Comments that basically repeat the code break the DRY principle
• "Don't rely on the properties of things you can't control"
• Try and abstract away things like, which kind of database you're using, which OS, whether you're client/server or just client etc.
• Tracer code - develop an entire vertical slice to check it all works and you're on the right track and keep that code (different to prototyping)
• Prototype to learn
• Leave assertions on in production code
• Exceptions couple routines and their callers
• Encapsulate resources into classes using the constructor to allocate them and the destructor to clean them up. Means garbage collection will clean up resources and in non-GC environments it will help remind you to clean them up
• "Abstractions in code, details in metadata"
• Design for concurrency even in non-concurrent environments - makes temporal couplings obvious
• Software is like gardening 
• Don't try to refactor and add functionality at the same time
• "think of Unit Testing as testing against contract"
• "Don't use Wizard code you don't understand"
• When faces with a problem, write down all ideas no matter how stupid and check that whatever makes them stupid actually stands
• Organise teams around functions of the product
• "Failure to meet usability criteria is just as big a bug as dividing by zero"
• Test your tests by purposefully breaking the code
• "Find bugs once" write test to detect bugs that you discover

The idea of using metadata extensively in a program is a new one to me. On the one hand I can see it adding some complexity at first for the code that reads the metadata from it's source (the Authors highly recommend plain text files for many reasons), also adding complexity in that you can't tell exactly what the code is going to do without having to look at both the code and the metadata. On the other hand, there is the obvious advantage of not having to recompile your code when some program you're dependent on starts sending you 6 messages at a time instead of 5. Also I've come across many situations where test code needs a copy of the details that the production code doesn't expose which if they both got the details from metadata would reduce the number of  changes needed from 2 to 1.

The book has obviously been a success and the respect the community gives to the authors has allowed them to publish an entire range of books, with the Pragmatic moniker, the website of which is here http://pragprog.com/. It is a sign of the confidence the book inspires in me about the authors that I've now purchased another book from their range and have a few more on my Amazon wish list.

Someone who has read many books on general programming practice may only gain a few insights from this book, but for someone with little reading in the area then this book comes highly recommended compared to it's competition.

Link to Buy the book on Amazon

Code Complete Review

This post is a review of the book Code Complete: A Practical Handbook of Software Construction by Steve McConnell

Code Complete is an immensely practical book focused on software construction. This means that after reading the 800+ pages, you'll have dozens of tips and new ideas that you can put straight into use in your day to day programming.

Code Complete is the most important book on programming I have ever read. If a budding programmer asked me to recommend a single book to them, this would be it. I was fortunate enough to read Code Complete just a few months into my professional career and it vastly improved my code. My degree is in Computer Science and whilst this made me aware of many tools and techniques in programming and why these techniques are how they are, there was little discussion of how to use the tools well, which is what Code Complete covers perfectly. Whilst reading through the book for a second time, many of the points seemed obvious to  but then things are only obvious if you know them and I still found plenty of new and interesting points that I hadn't remembered from the first read through.

Interesting comparisons can be drawn between Code Complete and Clean Code as they are both focused on writing code (though Code Complete is broader). Firstly, Code Complete cites a wealth of research and other books to provide evidence fro the points made, whereas Clean Code's arguments are more along the lines of logical persuasion. This point becomes more involved in places where the two books disagree, for example, in Code Complete, Steve McConnell cites research that says comprehension of a routine doesn't drop until it gets over a couple of hundred lines whereas Clean Code recommends to make routines shorter and then shorter still and most of the examples given in the book are less than 10 lines long (despite the evidence saying comprehensibility isn't reduced in routines 200 lines long, I'm currently more in favour of the Clean Code very short routine style). Commenting is another are where the two books disagree, with Code Complete devoting an entire chapter to comments and recommending leaving the comments in from the Pseudocode Programming Process (more on this later) whereas Clean Code encourages removing as many comments as possible in favour of shorter routines.

One of the main contributions of Code Complete is the Pseudocode Programming Process whereby when writing a routine, Steve McConnell recommends starting with comments describing the intention of that routine and then refining the comments iteratively until it would be easier to write the actual code. Then for each comment left, you write what should be a few relatively simple lines of code and leave the comments in to describe, on a higher level of abstraction, what each section of code does. The authors of Clean Code would change each comment into a routine containing the lines of code associated with it and the routine name would convey the same information that the comment previously did. This would work well as the comments at the end of the PPP should be a single level of abstraction above the code that is written.

Here are the things that I found new or particularly interesting:

•  Languages (including natural ones) and what you can express in them, may limit your ability to think certain thoughts
• Programming "in" a language - limit thoughts to constructs of language vs programming "into" a language - decide what you want to express and then work out how to express those thoughts via the language
• Final design should be neat and tidy but the path to tidiness isn't tidy (similar to writing unclean code and then cleaning it as expressed in Clean Code)
• To manage complexity - reduce accidental complexity and minimize how much essential complexity you need to remember at any one time
• Abstraction - you can look at a higher-level. Encapsulation - you can only look at a high-level
• The easier it is to call a module (int terms of setting up the right arguments) the looser the coupling
• Don't think of Abstract Data Type's as mathematical objects, but as a way of letting you work in the problem domain rather than low-level implementation
• Class = ADT + inheritance + polymorphism
• final for functions in Java is equivalent to non-virtual in C++
• inheritance tends to contradict reducing complexity
• Routines 100-200 lines long are no more error prone than shorter routines
• Correctness - never returning an invalid result, better no result at all vs Robustness - try to keep the software operating
• Consider creating a project specific base exception class
• Original coding (and review!) in pseudocode and leave pseudocode in as comments once code written
• Avoid "Just One More Compile" syndrome
• If you have to "figure out" a piece of code, refactor it
• Use positive boolean variables names to avoid double negatives
• Abbreviate consistently - not only just one of num/no. but also don't use Number and Num
• Create names you can pronounce
• Avoid misspelled words in names as you have to remember the misspelling
• Avoid often misspelled words
• Centralizing control over things that might change is good
• Random accessing into arrays (ie not sequentially) is similar to random gotos
• Put the normal case in the if not the else
• Prefer for loops to while loops as all the loop control is at the top in one place
• Make each loop perform only one function - Only combine loops if measured performance shows you should (and you need the extra performance)
• Don't change the index of a for loop inside the loop
• Simulate (in head) loop for 1st, last and random middle case to check it
• Consider table based approaches instead of complicated ifs/switch statements
• Prefer < to > as it orders arguments like a number line
• Code reviews more effective than testing because they find cause and symptoms whereas tests only find symptoms
• For data-flow testing, have a test case for each DEFINED-USED pair
• When debugging, consider how long brute-force techniques such as rewriting the routine would take
• "being wring about a change should leave you astonished"
• Larger projects will have lower productivity and high error density
• Write a core then code and integrate one class at a time
• When doing incremental integration, then you need to plan construction earlier
• Leave a dyadic operator on the end of a line to indicate the expression carries on

Overall, I would recommend Code Complete to anyone with an interest in programming and software development. Newcomers to the field will have the code improved invaluably by reading the book and experiences practitioners will still be able to learn something and also know that the good habits they have picked up are backed by evidence.

Link to but the book on Amazon.com

Clean Code Review

This post is a review of the book Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (and others).

Clean Code opens with the premise that it is not a "feel good", easy reading book, reading the book is not a passive activity but one that involves understanding and critiquing lots of code and thinking about the problems within it yourself before being presented with the authors' opinions of the problems. Whilst I agree with the justification given, I did "feel good" after reading the book, mainly because I had learnt so much and had been given an enthusiasm to get straight to my laptop and start refactoring my code.

For most people, Clean Code will tell you that you're doing something or many things wrong when you're programming. It provides well thought out arguments about why it's wrong to do things in certain ways and offers "cleaner" alternatives. Even if you disagree with the authors on a particular point, the reasoning given by the authors will help you realise when to adapt your approach. Many of the things pointed out as being wrong may well seem obvious yet, after reading the book I started noticing that these problems are everywhere, in my own code, in open-source projects and in advice on forums.

Here are some of the points that I found most interesting or were new to me:

• Try to check-in code a little cleaner than when you checked it out
• Don't encode the container type into the name (in case you change container type...)
• Don't slightly alter a variable name just to satisfy the compiler
• Don't add useless additional words to variable names, eg amount in moneyAmount, info in customerInfo
• Make functions small and then smaller (though more about in this in my upcoming review of Code Complete)
• Blocks within if, else and while statements should be small, preferably just a function call
• "If a function does only those steps that are one level below the stated name of the function, then the function is doing one thing" (functions should only do "one thing"!)
• The fewer arguments a function has, the better, be suspicious of functions with 3 or more arguments
• Encode name of arguments into function eg assertExpectedEqualsActual
• If functions are small, then multiple exit points are OK.
• Use good naming to make comments redundant and then get rid of the comments
• Hierarchically structure functions below the function they are called from
• Don't return null, removes the need for the clutter of null checking statements
• Create interfaces over 3rd party code to protect yourself from changes
• Write tests to discover and document how 3rd party APIs work
• 3 Laws of TDD:
  1. You may not write production code until you've written a failing unit test
  2. You may not write more of a unit test than is sufficient to fail (not compiling is failing)
  3. You may not write more production code than is sufficient to pass the currently failing test
• "Test code is just as important as production code". The only difference between the two should be that test code can be inefficient
• Try to minimise the number of asserts in a test (can be achieved by writing custom asserts as long as you can give the custom assert a sensible name)
• Classes should have one responsibility - only one thing changing should cause them to change
• Can separate classes from a large class by grouping by which member variables they act on
• "To write clean code, you must first write dirty code and then clean it"

The last point there is I think particularly important, the authors give the OK to writing code that gets the job done and the tests passing first, and then cleaning it up piece by piece until you have clean code.

The book is somewhat focused on Java, which manifests itself in various ways such as there being a chapter on JUnit and also some of the smells in the book are dependent on having the extensive IDE support that is available for Java. For example, the authors discourage the use of naming conventions to make member variables distinct from local and argument variables, saying that this distinction should be handled by the IDE. Which may not be the case if you're using a newer, less supported language. You certainly shouldn't let this put you off, the amount of general information in the book far outweighs any Java specific information and you can still gain insight from the reasoning behind any Java specific thought.

Possibly the most important part of the book is the collection of code "smells" and heuristics and the end of the book. These are things to look out for in code with explanations of why each one is bad and options on how to make it cleaner. This collection of smells with explanations makes the book invaluable as a reference. Clean Code has made me a better programmer and with repeated checking of it's list of smells, it will continue to do so. It has also driven up my enthusiasm for writing really good code, so I'd definitely recommend it to anyway who spends much time programming. If you're a programmer by profession, then your colleagues will definitely also be glad that you've read it.

Link to buy the book on Amazon.com

Object-Oriented Software Construction Review

This post is a review of the book Object-Oriented Software Construction by Bertrand Meyer.

Where to start with this massive tome? Weighing in with other 1200 pages and some pretty deep content, OOSC isn't a quick and easy read. The author bio describes Bertrand Meyer as equally at ease in the software industry and in the world of academic computer science" and his book also straddles the 2 disciplines. There's plenty of interesting material for academics and those interested in the theory, yet the book also contains much practical, useful information which software engineers can use in their day to day work.

Usefully the book uses a new language written by Meyer and others to demonstrate the concepts explained in the book, which makes them much clearer and allows Meyer to show the concepts in their purest form. The book comes with a CD with an environment for using this language (and an electronic version of the book), so you can play around with it to check your understanding of the concepts.

There are some points of controversy in the book regarding which direction is more object-oriented and Meyer acknowledges opposing choices to his and backs up his choices with well though out arguments. By choosing a strict object-oriented viewpoint in the main part of the book, you miss out on details that would be usable in a more common language than the one presented. Mayer addresses this with a section towards the end of the book about object-orientation in different languages, namely Ada, Simula, Smalltalk, C++ and Java as well as extensions for LISP and C. Though as you can see from the list of languages, the books suffers a little here from being originally published in 1994 with the second edition (the version reviewed) published in 2000.

Here are some of the points that I found most interesting or were new to me, there are a lot! (I didn't start taking notes til the 9th [of 36] chapters so there's nothing here from the first 8 chapters):

• You want 3 things from a garbage collector:
  1. Soundness - Collected objects are unreachable
  2. Complete - All unreachable objects are collected
  3. Timeliness - known average and upper bound on time from unreachable to collected
  Problems in garbage collection occur when passing arguments to functions in other languages.
• Inheritance and type parametrisation (genericity) are 2 perpendicular ways to be more generic. Reliability (type safety) and reusability (single language element covering different variants) are conflicting but can be solved by type parametrisation. Static typing gives you errors at compile time as opposed to at run time with dynamic typing and because the earlier an error is detected the cheaper it is to fix, this is an advantage of static typing (though does this rule really apply here?). Because of their unspeficiedness, generic parameters in functions can only be used in assignments, equals and calls to other functions that take generic parameters.
• For a component to be considered reliable, it must perform to it's specification and also handle cleanly, cases outside it's specification.
• There are only 2 legitimate responses to an exception: retrying or reporting a failure to the caller. If failing the catch block or equivalent must first restore the object to a steady state.
• An overlooked aspect of reusability is that a language should allow you to access code written in a different language. OO is more about the modular organisation of a system that the line to line coding.
• From the perspective of types, inheritance is specialisation, from the perspective of a module, inheritance is extension.
• Types can be useful when the code is being read by a human for showing intent (though in languages where you do not declare types, this information could be encoded into the variable name).
• When architecting a system, classes can be broadly classified into 3 types:
  1. Analysis classes - from the problem/domain space
  2. Design classes - architectural choice, in solution space
  3. Implementation classes - low level, in solution space
• Use cases can lead to a sequentially biased analysis and also model existing behaviour rather than coming up with new behaviour. (To counter this Mastering the Requirement Process recommends deciding where the boundaries of the work lie before working out use cases).
• Functions should be split into commands and queries, commands should not return a result and queries should not make change that are visible to clients of the class.

Towards the end of the book in the chapters covering concurrency and databases, the amount of general information starts to tail off as the text becomes quite specific to the solution used in the language that accompanies the book.

Overall, this is a very interesting book for fans of the theoretical side of software engineering. Readers who are solely looking for practical tips to improve their code, will find them but they may lose patience due to the massive amount of other information in the book.

Link to buy the book on Amazon.com

Mastering the Requirements Process Review

This post is a review of the book "Mastering The Requirement Process" by Suzanne and James Robertson.

The book describes a process for gathering and validating requirements based on the similar processes used and observed by the authors from many software projects. There are many forms and templates in the book to aid the process. The process described does seem a thorough way of gathering and recording requirements though I don't have any experience of other well-documented requirements processes to compare it to. On a first flick through the book, some agile enthusiasts may be put off with the large amount of forms described and process description but the authors very sensibly describe in each chapter, how they would adapt the chapter's contents depending on the agility of the team using the process and as the authors repeatedly state, regardless of how agile you are, if you don't find the correct requirements you won't be making the right product.

Here are some of the points that I found most interesting or were more abstract than the majority of the book:

• The book defines 3 types of requirements; functional - things the software must do; non-functional - qualities it must have; and constraints - global issues that shape what can and can't be done. It's a useful mini checklist to use for inspiration, as the initial excitement of a project is normally about the functional requirements, so a reminder that you need to plan for other things is welcome.
• Another repeated point of the book is that all requirements should be testable. Obviously some requirements are going to be easier to test than others but the authors aren't afraid to suggest such ideas as testing whether 90% of a panel of potential users can complete a simple task in 10 minutes, as a way of quantifying usability requirements which are the normally the hardest requirements to turn into measurable goals.
• Requirements can be reused between projects. As with code, it is suggested that there will have to be some adaptation but you can imagine that reuse of usability requirements would be very possible in products that target the same group of users for example.
• You need to strip away the current technology to get to the essence of the work. This often leads to products which are much simpler to use than their predecessors and can lead to innovative products which do the work in a very different way.
• Some useful suggestions are made for finding potentially missing requirements. Firstly a requirements to cover what happens when expected external events do not happen. Secondly, for every data class (obviously, I mean class in a high level sense) in the application, if there are requirements that describe reading, writing of updating it, then to check that there is a requirement covering creating of instances of that class.

In conclusion, I would say that the book is most useful to have as a reference rather than for explicitly learning too many high level concepts. The checklists and forms in the book provide a very thorough framework for capturing requirements. I can see the book being very useful for people working on their own projects, where it will help make you consider the product from other perspectives, and on the other extreme, also useful for people working in large organisations who need a strict framework and process for gathering requirements for large products. I am planing on using the process described in the book for a personal project, so I'll update this review when I have some feedback on how that worked.

Link to buy the book on Amazon.com

Weekly download statistics

So rather than going through the week totals for every week since I last did an update I'm just going to compare last weeks downloads agains the downloads from the 21st-27th May, which were the last ones I published.

App	21st-27th May	23rd-29th July
Get Mick Home Free	NA	98
Seesaw Saga Free	190	51
Zort Ball Free	1337	161
Grovr Folder Sizes Trial	422	112
Blackjack Free	2719	1363
Word Find Free	538	249
Charades Free	425	108
Video Poker Free	2603	4989
MultiSMS Free	1179	0*
Kitchen Timer Free	425	195
Interval Timer Free	420	198
Lyrics Quiz Free	715	151
Pause on Disconnect Trial	50	35
Pause on Disconnect	1	0
MultiSMS Pro	3	0*
Kitchen Timer Pro	1	1
Video Poker Pro	20	20
Blackjack Pro	12	11
WordFind Pro	10	8
Charades Pro	2	0
Lyrics Quiz Pro	1	2
Grovr Folder Sizes	38	6
Interval Timer Pro	12	3
Zort Ball Pro	1	0
Seesaw Saga Pro	0	0

*MultiSMS Free and Pro have been removed from the Ovi Store by Nokia because it "facilitate SMS or Email spam attacks" which is pretty much all it does (though not intended to be used in a malicious way) so I think that's fair enough of Nokia.

Monthy money statistics

Sorry it's been so long but I've been on holiday for a month and since then I've been busy making my new game Munch Them (available now) and porting games to Meego using the N950 Nokia have loaned me.

Month	Income from advertising	Income from app sales	Total
Jan 2011	£110.56	£75.15	£185.71
Feb 2011	£81.08	£67.28	£148.36
Mar 2011	£257.62	£114.92	£372.54
Apr 2011	£221.74	£124.15	£345.89
May 2011	£255.44	£207.38	£462.82
June 2011	£245.09	£150.13	£395.22
July 2011	£228.21	£158.30	£386.51

Making £395 in June when I was on holiday the entire time is really nice and it's nice to see income is pretty level even when I haven't got new products in the market.

I'll be posting my latest download statistics soon.

Weekly download and Monthly money statistics

Here are the weekly Ovi Store download statistics for the week of the 21st May to 27th May

App	14th-20th	21st-27th
Seesaw Saga Free	134	190
Zort Ball Free	671	1337
Grovr Folder Sizes Trial	1011	422
Blackjack Free	3185	2719
Word Find Free	1122	538
Charades Free	313	425
Video Poker Free	3109	2603
MultiSMS Free	780	1179
Kitchen Timer Free	265	425
Interval Timer Free	355	420
Lyrics Quiz Free	545	715
Pause on Disconnect Trial	110	50
Pause on Disconnect	1	1
MultiSMS Pro	4	3
Kitchen Timer Pro	0	1
Video Poker Pro	24	20
Blackjack Pro	7	12
WordFind Pro	17	10
Charades Pro	2	2
Lyrics Quiz Pro	0	1
Grovr Folder Sizes	41	38
Interval Timer Pro	9	12
Zort Ball Pro	1	1
Seesaw Saga Pro	0	0

Month	Income from advertising	Income from app sales	Total
Jan 2011	£110.56	£75.15	£185.71
Feb 2011	£81.08	£67.28	£148.36
Mar 2011	£257.62	£114.92	£372.54
Apr 2011	£221.74	£124.15	£345.89
May 2011	£255.44	£207.38	£462.82

So May is now my most succesful month ever and it's nice to see that app sales account for a larger part of the income, which means people think my apps are worth spending there hard earned cash on :)

This is the last one of these posts for a while as I'm going to be on holiday until July, but I'll post back all those statistics when I get back.

Weekly download statistics

Here are the weekly Ovi Store download statistics for the week of the 14th May to 20th May

App	7th-13th	14th-20th
Seesaw Saga Free	112	134
Zort Ball Free	488	671
Grovr Folder Sizes Trial	275	1011
Blackjack Free	2290	3185
Word Find Free	1420	1122
Charades Free	351	313
Video Poker Free	3246	3109
MultiSMS Free	933	780
Kitchen Timer Free	345	265
Interval Timer Free	660	355
Lyrics Quiz Free	627	545
Pause on Disconnect Trial	90	110
Pause on Disconnect	0	1
MultiSMS Pro	3	4
Kitchen Timer Pro	6	0
Video Poker Pro	27	24
Blackjack Pro	7	7
WordFind Pro	36	17
Charades Pro	2	2
Lyrics Quiz Pro	1	0
Grovr Folder Sizes	14	41
Interval Timer Pro	8	9
Zort Ball Pro	0	1
Seesaw Saga Pro	2	0

Weekly download statistics

Here are the weekly Ovi Store download statistics for the week of the 30th April to 6th May and 7th May to 13th May

App	23rd-29th	30th-6th	7th-13th
Seesaw Saga Free	315	82	112
Zort Ball Free	206	138	488
Grovr Folder Sizes Trial	106	75	275
Blackjack Free	1661	1583	2290
Word Find Free	358	455	1420
Charades Free	186	142	351
Video Poker Free	4603	3366	3246
MultiSMS Free	202	249	933
Kitchen Timer Free	92	90	345
Interval Timer Free	210	242	660
Lyrics Quiz Free	206	169	627
Pause on Disconnect Trial	43	56	90
Pause on Disconnect	2	1	0
MultiSMS Pro	3	1	3
Kitchen Timer Pro	0	3	6
Video Poker Pro	20	20	27
Blackjack Pro	3	5	7
WordFind Pro	9	15	36
Charades Pro	4	0	2
Lyrics Quiz Pro	2	1	1
Grovr Folder Sizes	2	5	14
Interval Timer Pro	10	5	8
Zort Ball Pro	1	1	0
Seesaw Saga Pro	0	0	2

.
Quite an encouraging set of figures in terms on sales, I'm certainly looking forward to totting up this month's income totals.

Monthly money statistics

Month	Income from advertising	Income from app sales	Total
Jan 2011	£110.56	£75.15	£185.71
Feb 2011	£81.08	£67.28	£148.36
Mar 2011	£257.62	£114.92	£372.54
Apr 2011	£221.74	£124.15	£345.89

So April was slightly down on March but did see an increase in income from App sales which as always nice to see as it means that people think my apps are worth spending money on.

These figures are somewhat rough in that they are based on the estimated revenue from sales and also a rough calculation of the exchange rate. They do not reflect actual money that I have recieved into my bank account.

Weekly download statistics

Here are the weekly Ovi Store download statistics for the week of the 16th April to 22nd April and 23rd April to 29th April

App	9th-15tht	16th-22nd	23rd-29th
Seesaw Saga Free	NA	567	315
Zort Ball Free	1182	502	206
Grovr Folder Sizes Trial	90	102	106
Blackjack Free	4425	1995	1661
Word Find Free	485	412	358
Charades Free	190	187	186
Video Poker Free	3530	4235	4603
MultiSMS Free	402	246	202
Kitchen Timer Free	138	118	92
Interval Timer Free	234	171	210
Lyrics Quiz Free	284	227	206
Pause on Disconnect Trial	59	64	43
Pause on Disconnect	1	0	2
MultiSMS Pro	7	3	3
Kitchen Timer Pro	0	0	0
Video Poker Pro	8	29	20
Blackjack Pro	9	3	3
WordFind Pro	3	2	9
Charades Pro	0	0	4
Lyrics Quiz Pro	0	1	2
Grovr Folder Sizes	1	6	2
Interval Timer Pro	13	9	10
Zort Ball Pro	2	4	1
Seesaw Saga Pro	NA	2	0

.

New game Seesaw Saga released

I'm pleased to announce that my new game Seesaw Saga is now available on Ovi Store.

In Seesaw Saga there are 10 different levels and on each level you have a certain number of bricks of different sizes and shapes that you have to drop onto a seesaw, the aim of the game is to drop all the bricks without letting the bricks fall of the seesaw. You gain more points on each level by dropping the bricks from higher up the screen and larger bricks are worth more points. If you score enough points, you are rewarded with a medal, you need to get a bronze medal on a level to unlock the next level. The game also keeps track of your highscores for each level. The different levels have different obstacles, different drop areas and different bricks to drop.

Seesaw Saga comes in two versions, an ad supported free version available here: http://store.ovi.com/content/118212 and a Pro version with no adverts for 1 Euro or equivalent available here: http://store.ovi.com/content/118209

Weekly download statistics

Here are the weekly Ovi Store download statistics for the week of the 9th April to the 15th April

App	2nd-8th	9th-15th
Zort Ball Free	765	1182
Grovr Folder Sizes Trial	100	90
Blackjack Free	5585	4425
Word Find Free	403	485
Charades Free	230	190
Video Poker Free	3734	3530
MultiSMS Free	968	402
Kitchen Timer Free	244	138
Interval Timer Free	291	234
Lyrics Quiz Free	373	284
Pause on Disconnect Trial	25	59
Pause on Disconnect	0	1
MultiSMS Pro	10	7
Kitchen Timer Pro	1	0
Video Poker Pro	3	8
Blackjack Pro	11	9
WordFind Pro	8	3
Charades Pro	1	0
Lyrics Quiz Pro	2	0
Grovr Folder Sizes	4	1
Interval Timer Pro	11	13
Zort Ball Pro	NA	2

.

Weekly download statistics

Here are the weekly Ovi Store download statistics for the week of the 2nd April to the 8th April

App	26th-1st	2nd-8th
Zort Ball Free	NA	765
Grovr Folder Sizes Trial	122	100
Blackjack Free	6910	5585
Word Find Free	972	403
Charades Free	491	230
Video Poker Free	4114	3734
MultiSMS Free	3222	968
Kitchen Timer Free	1074	244
Interval Timer Free	870	291
Lyrics Quiz Free	1583	373
Pause on Disconnect Trial	69	25
Pause on Disconnect	2	0
MultiSMS Pro	19	10
Kitchen Timer Pro	4	1
Video Poker Pro	3	3
Blackjack Pro	18	11
WordFind Pro	7	8
Charades Pro	2	1
Lyrics Quiz Pro	1	2
Grovr Folder Sizes	6	4
Interval Timer Pro	6	11

Generally a downward trend this week compared to last, though last weeks figures were very high. Although Zort Ball Free has only been out a few days rather than a whole week, I was expecting it's downloads to be higher, closer to the initial releases of Blackjack and Video Poker, having said that, I have already recieved some useful feedback via Ovi Store reviews and a new version is going through QA now with larger buttons.