5 Reasons to Keep Software Projects Small

Thoughts of system architecture have been cropping up recently so I wanted to layout some reasons why keeping software projects small is a good thing. A small software project is one that has one main purpose and few features. A small software project can be described to a new person in one sentence: "that's the product catalogue repo, it hosts a public list of products for our clients and has an authenticated admin console." Here's why you should Think Small.

5. Code Ownership

Let's start with the obvious one, maintainability. People, developers included, generally take more care of their own stuff than others'. Software is no different. It's a side effect of keeping projects small, but a very good one: Those projects written by one or two developers will be much better looked after and cared for than projects with multiple owners. I know this because I have worked on small projects written by a few people and large projects written by many. It is less likely for a developer to feel engaged when they are 'in someone else's code'. Motivation is lacking and code craftsmanship suffers when devs are contributing to a project that they do not feel ownership of. Their best work is rarely produced and what does get committed can often contradict other areas of the system in terms of coding style or naming conventions. Over time, unless significant effort is made to enforce standards and motivate developers to take ownership then these changes turn big projects into a Big Ball of Mud. Once that happens, no one wants to work on the project and progress halts. TDD and clean code can help, but they are only preventative measures.

With smaller projects, its much harder to end up in a BBoM situation. There simply isn't that much code in the system. Projects are kept from reaching the point where no one is confident in making changes because the project responsibilities are few and its purpose well defined. You cannot accrue technical debt in a project with no room to take short cuts. And if there are, then they are easy to spot. Its easy to answer questions organisation questions as the need for a clearly named folder structure is minimized.

4. Point Person

That is the go-to-guy when questions are asked or when changes are needed. When there are multiple point-people it usually requires a meeting just to make a decision, or worse, leads to deflection of responsibility. When the one point person knows that they are the only owner, they are driven to have detailed understanding of the system's behaviour (as chances are they have written it). The knowledge should be detailed but easy to pass onto another dev, should the original author move on. Failing that, small systems permit re-writes much more readily that large ones. As for the business, its not the nuances of the particular framework that is valuable, but the role that the system plays instead. This information is more transferable with smaller projects.

3. Quality Requirements

When describing a small system, its much easier to gather the quality requirements. These are things like performance, uptime, security, accessibility, scalability etc. The audience or clients of a small system are usually more focused which lets us make design calls in the code. What is the expected throughput of the url? How soon after event x must the event data be query-able? Will we need to serve content to the other side of the world? Mobile?! When the developer knows the extent of the system's purpose they can make judgements about these kind of questions more easily.

2. (Re)Distribution

This point is about how the system can be accessed. Keeping systems small means that they can be consumed more easily in different formats. Obviously, the most common mechanism of communication is over HTTP. The reason it is so popular is because of the high number of client libraries that support the http request response model with JSON data binding, meaning language interoperability. Http also provides built in functionality for authorisation, caching and security. But the benefits of http are not exclusive to small projects. What small projects are suited to is packaging. A packaged product or library is focussed on doing one thing really well. And when a project has few responsibilities then it can be packaged easily. This becomes a virtuous circle when you consider the motivation for packaging. It makes code shareable and more re-usable. Modern systems are a composition of frameworks and libraries brought together in a particular way to provide unique functionality. Package managing tools permit rapid development by providing access to thousands of small systems that have been packaged, used and tested by others.

1. Innovation

Developers like learning new tricks and using new tools. When what the business is asking for can be delivered in small projects it benefits the business and the developer. If a developer has heard about and new framework or library they would like to try out, then they are going to be twice as motivated to take ownership of the system and enjoy the development experience when they get the chance to try it out. It might take slightly longer as learning occurs, but the development team wins as a result. New knowledge is shared and as such the team becomes more experienced. When some work arrives that has to be out the door by Friday, the team that has the most varied experience are more likely to already know the best tool for the job - and deliver. Aiming for small projects means that a team members acquire new skills more frequently as there are more opportunities to try out something new. Innovation and discovery in IT can be a driver for success in digital industries, thinking small might just give your team the advantage.

Heroku's Python Web Sockets Chat App Locally on Windows with Vagrant

Heroku have recently announced support for Web Sockets. They have provided a selection of code examples in various languages to illustrate the two-way communication enabled by web sockets. The focus of this article is the Python-Websockets-Chat application.

Provided is a walk-through for producing an app that will work on Heroku, taking advantage of the redis add-on that will be part of your infrastructure when your environment is created at set up. I wanted to get a better understanding of Python, Flask and the web sockets plugin, Gevent, so I needed to play with the application locally. This required some help from Vagrant. I've been over the benefits of Vagrant before in a similar article so no need to repeat myself.

The pre-requisites to having a running instance of the Python-Websockets-Chat application are numerous and complicated. Starting with a fresh Ubuntu Precise32 Vagrant box will take at least 15 minutes of install time to correctly configure the environment. Thankfully, the provisioning capabilities of Vagrant mean that we can kick off the 'Vagrant up' command in the project directory and just wait for the bootstrap shell script to do its thing.

The shell script is shown below. As you can see there are not only dependencies on python development tools and Pip - the Python plugin manager, but Ruby also. This is because the application is designed to run on Heroku which uses a Procfile to organise the processes that need deploying. Procfiles are best executed by a Ruby gem called Foreman, hence the dependency. Other than that there is the requirement to install and kick off Redis, followed by the Foreman start command to trigger the app into action. It should be available on your host machine at http://localhost:5000/.

	sudo apt-get update
	sudo apt-get install python-dev -y
	sudo apt-get install python-pip -y
	sudo apt-get install libevent-dev -y
	sudo apt-get install ruby1.9.1-full -y
	sudo apt-get install build-essential -y
	sudo apt-get install tcl8.5 -y
	sudo wget http://download.redis.io/releases/redis-2.6.16.tar.gz
	sudo tar xzf redis-2.6.16.tar.gz
	cd redis-2.6.16
	sudo make
	sudo make install
	sudo gem install bundler --no-rdoc --no-ri
	sudo gem install foreman --no-rdoc --no-ri
	cd /vagrant
	sudo pip install -r requirements.txt
	redis-server &
	foreman start

view raw bootstrap.sh hosted with ❤ by GitHub

Please see my forked repo of the chat app for all the code in one place.

Anyone with some experience in Linux will recognise a lot of this as incredibly basic instructions, understandably. This post is for the benefit of the Windows folk who have next to no knowledge of configuring Linux environments and just want to see results. That's part of Vagrant's goal, to simplify and centralize environment configuration, so I hope that this goes some way to helping that cause.

P.s. Windows users be sure that the line endings of the bootstrap.sh are in the linux format (LF) and not the Windows format (CRLF). Cloning the repo may have adjusted your line endings so if you run into a problem when the bootstrap.sh tries to be executed then please see this issue on github.