February 6th, 2010
Over the life cycle of a project many features may be developed, sometimes just to account for one variation or tiny use case, get used once, and are then not used again for the next 5 years (if ever).
One of my personal pet peeves is overly complicated software with too many redundant, old, unused features. This sort of redundant complexity increases the learning curve for new developers coming into the software project and creates extra work in maintaining the software,
I often think the best way to create and maintain software, is to periodically remove all the old crap not being used any more. Some people do not like the idea of losing a feature in their application, as in “OMG, you can’t take that away, I was planning to use that one day”, and maybe they were. But often, you have to look at what they say they are going to do, and compare that with what they actually do.
I am sure this is some sort of psychological effect where the fear of losing a feature has more of an emotional impact on the end user / client than the prospect of faster software development and the addition of new features, as well as cheaper maintenance.
If the feature works, can’t it just stay?
Hypothetically yes, but sometimes the part the end user sees is that the old features only continue to work because when adding new features we are able to test we have not broken the old features, and in some cases that means a ton of work when a big structural change is occurring.
Also consider the development of a new software project, or a big addition to an existing project. The number of proposed features grows exponentially with the number of people involved. In reality, only 20% of the features will make 80% of the software, but you may end up coding 80% of the features to make up 90% of the functionality, just because people don’t get agile, or the business structure around you does not allow for it to happen so easily (extensive budgeting approvals, waterfall methodology), or of the HiPPO effect (Highest paid person’s opinion).
This post has been a bit of a rant, but the points are these:
* Don’t develop crap you don’t need
* Remove old crap you don’t use any more
Do points 1 & 2 and you will get:
* Faster software development
* Software that is easier to maintain
* Easier to bring in new developers to a project
* Happier developers
* Reduced costs all round
Categories: Productivity
Tags: agile, development, philosophy
January 15th, 2010
There is a nice little tool over on tmto.org that allows you to decrypt (or should I say, reverse) MD5 or SHA1 hashes. Essentially, someone has forward hash’ed all a-z letters, put them in a database, then matches your hash against what is in the DB to find what the original string was. This is somewhat limited, it only currently does a-z by the looks of things, but a very nice idea. Should also re-enforce the benefits of double-salting your passwords with a per-size and per-user based salt as well.
Categories: Uncategorized
August 6th, 2009
I think autotest is one of the best things about developing in Rails. If you don’t know, autotest runs in the background watching all of your application files. When you edit any of them, it automatically runs the sections of your test suite that apply to the modified file, and can then give you feedback as to if your tests are passing or failing. This means more time developing, less time switching windows to run rake test!
I thought I would post a note about how to correctly install autotest, as some of the other documentation is out of date.
sudo gem uninstall ZenTest
sudo gem install ZenTest
sudo gem install autotest-rails
Something that is missing in a lot of other online documentation is the fact that you have to install the autotest-rails gem as well, if you don’t do this, you will get an error any time you try to run autotest:
Autotest style autotest/rails doesn't seem to exist. Aborting.
Another note, if you want to get desktop notifications working, this page has details of how to achieve that using Mac OSX, KDE, Gnome, etc.
Categories: Productivity, Rails, Testing
Tags: autotest, Testing
July 25th, 2009
A really useful way to mockup your applications before coding is to use wire framing software to create the screens and layout of your application. By doing this, you can ensure everyone working on the project can help to decide upon what the first version should functionally look like, and everyone will know what the end goal should approximately look like.
With this sort of discussion, you really need a tool that will just let you focus on the functional aspect, and avoid too much discussion about colors, branding, etc, all of which can come later.
A really useful tool I have been using is Balsamiq Mockups, it allows you to quickly create screens for your app and includes all the standard page controls you would expect. Here is an example of what you can produce:
There is a nice video demo on the site as well.
Categories: Uncategorized
July 11th, 2009
Something I have been asked a few times by online retailers is, “how does my conversion rate compare to others in my industry?“. Speaking to one online retailer a few weeks ago, they specifically mentioned having access to lots of data from Google analytics, but they have no idea if they are doing better or worse than their competitors or others in their industry.
If you work with E-Commerce, check out the Fireclick Index which publishes a list of conversion rates for different types of e-commerce websites each month, and that can offer some sort of guide as to average conversion rates, and how you are performing.
You should of course be aiming to out perform the average, as this makes your advertising cheaper (lower customer acquisition costs), can result in a higher absolute number of customers, which can result in a higher absolute number of repeat-sales.
Categories: Conversion
Tags: conversion rates, e-commerce
