Single Responsibility Principle

“There should never be more than one reason for a class to change.”

The first principle is the cornerstone of the set and gives the greatest return on investment when followed correctly.  It states that each class should have only a single responsibility and therefore reason to change.  Keeping each class small and tightly focussed allows developers to know exactly where to go to find or add particular functionality to the game. 

Why is having more than one responsibility bad?  Multiple responsibilities means there is coupling between separate pieces of code.  Changes to one responsibility reduce the ability for the class to meet the requirements of the other responsibilities.  This leads to fragile design that breaks often and in unexpected ways.  “Why did changing from rendering API break jumping in the game?”

The way to fix code that breaks this principle is to separate each responsibility into its own class.  The first step can be to extract an interface per responsibility.  Other classes can then rely on these interfaces rather than the class itself.  The class can then safely be split up into separate classes for each responsibility that each implements a single interface.

When have you got it? – The usual culprit breaking this principle is that one (or group) class that’s hundreds or thousands of lines long.  You know the one I’m talking about. Often it’s the GameObject or Entity class that everyone seems to throw code into.  This class usually has about 500 reasons to change, and therefore 500 responsibilities.  It’s usually involved in the heinous bugs that crop up constantly.

Open Closed Principle

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

The goal of this principle is for each class to change as infrequently as possible while allowing it to be used in as many situations as possible.  While these two requirements may seem at odds they actually complement each other to generate robust design.  A class is open for extension means that the behaviour of a class can be changed in new and different ways as the requirements change.  A class is closed for modification when no source code changes are required for these changes in requirements to be met.

This principle can easily be resolved with data driven design.  By passing the required configuration data to a class it can easily be extended reducing its need for modification.  Any variables (in the mathematical sense) should be passed to the class so that the classes definition itself (the code) does not specify the functionality of the class alone.  I find this the easiest to think about in terms of the basic OOD principle of data and operations.  The class defines the operations it can perform (its functions) and the data that it operates on.  As much of this data as possible should be passed to the class/function.  This moves the configuration of its data outside the class itself to the calling code increasing its ability to change.

When have you got it? – This is the file you dread checking-in because everyone seems to be working on it all the time.  No matter what system you’re working on, these files always seem to be involved.

Liskov Substitution Principle

“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”

Inheritance and polymorphism are powerful mechanisms for solving complex problems with simple solutions.  They are also powerful mechanisms for creating bugs and problematic code.  This principle involves making sure inheritance hierarchies are sound and not being abused by code that introduces bugs that are hard to find.  While it seems simple on the surface, this principle can be quite complex to solve correctly.

The first steps to solving this problem are to find instances of checking for an objects type – both its own and that of objects it’s working on.  Beyond this easy first step comes a principle known as “Design By Contract”.  Each function has a set of conditions that must be true before it is called (pre-conditions) and a set of conditions it guarantees are met after its completion (post-conditions).  These are often implied conditions kept in the mind(s) of the programmer(s) working on them.  The first step is formalising these conditions into code.  Once this step is completed the following rule can be met – “Derived classes can only weaken pre-conditions and strengthen post-conditions”.  Put another way, functions of a derived class should expect no more than their base class and promise no less.  This principle is important because of the fact a model viewed in isolation cannot be meaningfully validated.  You don’t know whether your new “Tank” class is valid until you run it in the context of its parent, siblings and other game system.

When have you got it? – Classes breaking this rule are really easy to find.  Look for any base class that uses run-time type information (RTTI) to interrogate its own type (or the type of an object it’s working on).  As soon as the GameEntity class is checking if it’s of type “Tank” to do some special code, you’ve broken this principle.  The class should be able to polymorphically call functions without caring about the actual type of the object.

Interface Segregation Principle

“Clients should not be forced to depend upon interfaces that they do not use.”

Interfaces should be used for communication between different objects to encourage clean, modular code. This principle takes that concept further by making sure that the interfaces we use are themselves clean and unified. The larger the interface, the more the client is relying on functionality of another object. By keeping small segregated interfaces each object will rely upon only the smallest set of functionality it actually requires. This reduces the complexity of links between objects and more importantly, lets someone reading your code know exactly what each class relies upon. Rather than one “fat” interface we break the interface up into multiple smaller groups of functionality that each serve a different client.

This principle links back to the single responsibility principle nicely. In this case each interface should have a single responsibility. This lets you explicitly state the functionality requirements of each object based on the interfaces it requires.

When have you got it? – Look at all your interfaces (abstract classes) and make sure their listing of functions are homogenous.  An easy way to tell you’ve broken this principle is when there are small groupings of functions within the interface definition.  Whitespace is the key here, the more whitespace between the groups of functions, the more disparate they are.

Dependency Inversion Principle

“High level modules should not depend upon low level modules. Both should depend upon abstractions.”

“Abstractions should not depend upon details. Details should depend upon abstractions.”

This is a key point that I had not heard of at all in game development until recently. This principle is quite the opposite of how many developers are used to working. Usually, if a class depends on another class, the client will instantiate an object of that class and then act upon it. Dependency Inversion (also called Inversion of Control) turns this on its head. Instead of the client being responsible for creating the object, it is given the object it depends on. This takes the control away from the client and moves it to the owner of the client, often the game engine.

A good example of this is in a rendering system. Rather than instantiating a rendering object, or directly calling the classes of the rendering API, the rendering system should receive an interface to the low level rendering functionality. By relying on an interface that is given to the rendering system, the low level rendering API can be changed without making breaking changes to the client rendering system. It becomes obvious if breaking changes occur as the low level rendering API’s interface will require changing.

When have you got it? – When two systems are talking to each other, how do they do it?  If they are using concrete classes then look for opportunities for them to rely on interfaces instead.  The best way is for the class to take as parameter to its constructor an interface reference to the class it needs to work on.  This also makes it obvious what sub-systems are particular class is reliant on.

Conclusion

What are your thoughts on the SOLID principles? Do you see benefit from adopting these in the games industry as web and application development has done?

SOLID Motivational Posters, by Derick Bailey

The game will be available on the app store on the 15th December and we’ll have more info in the coming days on Facebook and Twitter and our site.

Check out our first trailer below and watch this space for updates on the game and behind the scene’s look into how we created it.

What fanatical pragmatism is

Fanatical pragmatism involves pursuing the optimal product as cost effectively as possible, without cutting corners.  For anything non-trivial, see if there is an existing solution that can solve the problem.  For games, this involves using a 3^rd party engine, particle system, etc wherever possible.  It’s about solving the problems that need to be solved, in the cheapest way possible.

It’s good for developers as focuses them on completing as much as possible, as quickly as possible.  It’s also good for the business as it means the problems the business exists to solve are solved as cost effectively as possible.

What fanatical pragmatism isn’t

It is not about cutting corners to get to a solution faster.  Nor is it about ignoring long-term goals to reach short-term goals faster.  Fanatical pragmatism is not “cowboy coding” (rather it’s tangential to it) and it’s more about solving the businesses needs for the least cost than just getting things done quickly.

How scrum fits in

It fits in perfectly with agile development practices, particularly Scrum.  Scrum is a discipline-agnostic framework that gives developers the freedom to work within their own specific style.  For this reason, fanatical pragmatism works hand-in-hand with extremely short sprints and meeting changing customer demands.  It acts on high-level sprint planning (deciding what goes into a sprint) as well as low-level, day-to-day development such as exactly how to solve the tasks for a given sprint.  For this reason it can be embraced by both developers and management alike.

Some general rules

Some general rules I’ve found myself following recently:

• Broaden your knowledge.  I’ve spent the last couple of years running a software company focussed on web applications.  I’ve picked up a lot of skills that I’ve been able to transfer over to game development (and vice versa).  The broader your knowledge, the large the pool of resources you can draw from to solve problems.  The jack of all trades is the master of fanatical pragmatism
• Focus on the goal.  The key to keeping pragmatic is always looking at where you are heading.  Every decision from day-to-day task assignment to strategic planning should focus on where the team is heading.  All efforts should be in driving the team towards their ultimate goal(s).

Some general software development rules:

• Separate your concerns.  A big part of why MVC works so well for a game engine is that it keeps the obvious concerns (e.g. gameplay vs. rendering) separated from each other.  This keeps each person on the team focussed on their part of the problem domain and helps to reduce complexity as the software grows in size
• Clean Interfaces.  Keeping loosely coupled systems is a great way of isolating your code so that any mistakes made, or changes needed can be done with the least amount of hassle in the future
• Build strong architecture where it’s needed.  For some large, complex system’s it’s important to spend the time up front designing the architecture for the system.  This gives everyone a foundation to build upon.  This should only be done in rare situations though.  It’s easy to get caught in the trap of doing lots of big design up front, however fanatical pragmatism calls for this only when absolutely necessary, and enough information is known.

Conclusion

So that’s fanatical pragmatism in a nutshell.  Share your thoughts on the topic and let me know how you work best in achieving your goals.  I’m constantly evolving the way I work and I’m always looking for the best way to solve problems so please leave a message with your best practices.

The course runs over two full days and was the first course of this length where I didn’t fall asleep.  The content was of a high quality and was kept interesting with lots of interactive tasks and small group discussions.  Clinton began with a great overview of Scrum and then dug deep in to the details, explaining all concepts in great detail, without bogging down in minutiae.  While there was a slight programmer emphasis he covered all facets of game development.

Clinton has a lot of experience with general game development and is a pioneer with implementing Scrum in game development.  His stories were not only interesting but served as a great way to show how Scrum is being used in the real world.  He has worked with some big studios including CCP (creators of Eve Online) and Bioware.  This gives him both credibility and a great insight into how large companies have made successful games using Scrum.

The last part of the second day was spent simulating a handful of sprints to get a feel for how the interactions worked between ScrumMaster, product owner and the team.  The use of lego to create a small world was surprisingly similar to software development and served as a great way to simulate a small development cycle.  This brought the whole group together and let them experience the realities of working with Scrum in a group of people.  It allowed us to put into practice what had been learnt over the past two days.

An obvious benefit is the certification received at the end of the course.  However more important was the knowledge gained during the course.  I had a fairly good understanding of Scrum before the course however this helped to fill all the holes and even correct a number of misconceptions I had.  There are a lot of resources on the net and in books that can teach the basics of Scrum however I found that the interactive and hands-on nature of the course taught me things I would never have picked up through reading or trying to implement Scrum in a vacuum within my own team.  This is the primary reason I would recommend the course to anyone looking to adopt Scrum in the software development team.  Most people admitted to using a “version” of Scrum which by the end of the course proved to not have some of the essential ingredients.

One of the great points of the course was the high level of interactivity.  We could ask questions at any time (which people did) and Clinton would often integrate his answer into the rest of his talk give context rather than a simple answer.  He was happy to answer the hard questions about Scrum including where it has its problems and where we are likely to run into trouble.

I highly recommend the course to any lead’s or project managers.  While the cost of $1500 is fairly high (it’s the standard cost of any ScrumMaster course) it pays for itself in the payoffs you will experience within your team.  It’s an enjoyable two days where a lot is learnt and most will be inspired to fix the problems with the way their teams are managed.

Have you participated in a certified ScrumMaster course?  Have you attended one of Clinton’s courses or talks?  What do you think of Scrum and its relevance to video game development?

.mischief.mayhem.soap.
http://msinilo.pl/blog/?feed=rss2

Atom
http://farrarfocus.blogspot.com/feeds/posts/default

Beautiful Pixels
http://feeds.feedburner.com/BeautifulPixels

Dead Voxels
http://deadvoxels.blogspot.com/feeds/posts/default

Diary of a Graphics Programmer
http://diaryofagraphicsprogrammer.blogspot.com/feeds/posts/default

direct to video
http://directtovideo.wordpress.com/feed/

Gamasutra
http://feeds.feedburner.com/GamasutraNews

Game Angst
http://gameangst.com/?feed=rss2

Game Rendering
http://www.gamerendering.com/feed/

GameArchitect
http://gamearchitect.net/feed/

GameDev.Net
http://www.gamedev.net/xml/

Geeks3D Forums – 3D-Tech News Around The Web
http://feeds2.feedburner.com/Geeks3DTechNewsForum

GPGPU» :: GPGPU.org
http://www.gpgpu.org/cgi-bin/blosxom.cgi/index.rss

Graphic Rants
http://graphicrants.blogspot.com/feeds/posts/default

Graphics Size Coding
http://sizecoding.blogspot.com/feeds/posts/default

Humus
http://www.humus.name/rss.xml

Ignacio Castaño
http://castano.ludicon.com/blog/feed/

John Ratcliff’s Code Suppository
http://codesuppository.blogspot.com/feeds/posts/default

level of detail
http://www.jshopf.com/blog/?feed=rss2

Level of Detail
http://levelofdetail.wordpress.com/feed/

Lost in the Triangles
http://feeds.feedburner.com/LostInTheTriangles

Make It Big In Games
http://makeitbigingames.com/feed/

meshula.net
http://meshula.net/wordpress/?feed=rss2

OpenGL News
http://www.opengl.org/news/rss_2.0/

NVIDIA Developer News
http://news.developer.nvidia.com/rss.xml

Outside Hollywood
http://www.outside-hollywood.com/feed/

Real-Time Rendering
http://www.realtimerendering.com/blog/feed/

realtimecollisiondetection.net – the blog
http://realtimecollisiondetection.net/blog/?feed=rss2

Sanders’ blog
http://sandervanrossen.blogspot.com/feeds/posts/default

Scattered Pixels
http://feeds.feedburner.com/ScatteredPixels

Solid Angle
http://solid-angle.blogspot.com/feeds/posts/default

The Hacks of Life
http://hacksoflife.blogspot.com/feeds/posts/default

w00t
http://bpeers.com/blog/xml-rss2.php

The Pragmatic Programmer: From Journeyman to Master

Code Complete

Rapid Development: Taming Wild Software Schedules

Agile Software Development, Principles, Patterns, and Practices

Refactoring: Improving the Design of Existing Code

Peopleware: Productive Projects and Teams

The Mythical Man-Month: Essays on Software Engineering

Design Patterns: Elements of Reusable Object-Oriented Software

Software Estimation: Demystifying the Black Art

Patterns of Enterprise Application Architecture

Software

1. Download Visual Studio 2008 Express – http://bit.ly/VCSExp

2. Download XNA Game Studio 3.1 – http://bit.ly/XNAGS31

Learning C#

3. Read these C# tutorials

a. C# Station Tutorial – http://bit.ly/CSTut1

b. C# WikiBooks – http://bit.ly/CSWiki

Learning XNA

4. Read these XNA tutorials

a. Introduction – http://bit.ly/XNATut1

b. 2D Introduction – http://bit.ly/XNATut2D

c. 3D Introduction – http://bit.ly/XNATut3D

5. Look at these starter kits – http://bit.ly/XNAKit

Other Links

6. Visit the following for more information on game development

a. Gamedev.net – http://www.gamedev.net/

b. Gamasutra – http://gamasutra.com/

c. Indie Gamer Forums – http://forums.indiegamer.com/

What should you create?

I’ve found the best way to learn game development is by creating a full game.  Exactly what game you create depends on what you want to get out of game development.  There are a number of paths I commonly see people taking:

• Becoming a game programmer – The best route here is to take an existing game like Pong, Space Invaders or Mario and recreating it.  The game design done is already complete, allowing you to focus on learning the skills required to code the game
• Becoming a game designer – Rather than recreating an existing game, come up with a new, simpler design.
• Getting a job at a particular game company - Before you begin your new game, you should find out what technology the company is using.  You are much more likely to be hired by them if you are experienced in their technology suite.  If you’re unsure of what they use, ask them.  Game companies are always looking for good talent and they’ll be happy to share the technologies they use with you.

Want more?

I’d like this list to become a comprehensive, step-by-step introduction to game development that takes developers from zero experience to creating their own 3D (or 2D) games.  If you get to a point where you’re stuck and don’t know what to do next, please email me and I’ll help you fill in the blanks.

Problem

When you chose an engine or platform to develop for, you’re locking yourself into its scripting language.  This has the following core problems:

• Difficult cross platform development.  Cross platform development is hard enough without the worry of porting gameplay code.  Gameplay code should not be platform specific, and therefore there is no reason to have a different language per platform/engine.
• Immature languages.  With each company re-inventing the wheel when they implement a new language designers are left with immature languages.
• Too many languages.  Designers must learn a new language whenever they develop for a new engine/platform.  This increases development time and reduces fluency in a language.  A designer cannot be free to fully express themselves until they are fluent in the language they describe their gameplay in.

Solution

The solution to these problems is to have a unified scripting language shared by all engines/platforms.  Written specifically for game development it would take the best of current scripting languages.  The games industry as a whole would “own” the language allowing it to evolve with the needs of the industry as each new generation of hardware is released.

Advantages

There are a number of key advantages for moving towards a unified scripting language.

• Single gameplay codebase.  Gameplay doesn’t change dramatically between similar platforms (e.g. 360 and PS3 or flash and iPhone).  A unified language would allow a single codebase to kept across multiple platforms helping with porting and maintenance.
• Specific to game development needs.  A language created specifically for game development could cater to the needs of the industry.
• Single language for designers to use. Small nuances in existing languages can create major issues for non-programmer designers.  A single unified language reduces these problems and makes the learning path for students clearer.
• Less Wheel Re-Invention.  An open-source unified scripting language would allow anyone to submit changes to the language to improve it, rather than re-inventing a whole new language.
• Unified Toolset.  A unified set of tools could sit on top of a unified scripting language.

Genre Specific

The core language will hold the basic building blocks for all games.  In the future, small libraries can be built by studios or the community for each specific genre.  For example a library of functions common to most FPS or RTS games could be created and shared between developers.   A unified scripting language makes this sharing possible and encourages people to develop well thought out, robust libraries they can reuse from engine to engine.  It also serves to soften the blow for designers when changing engines as their common set of functions will move across with them.

How

There are two main options for the creation of a new unified scripting language:

• Large studio forks their current language.  For example Epic could open up Unreal Script and give out the source code for its implementation (let’s call it OpenUnrealScript).
• Community Driven.  A simple codeplex/google code project with a couple of leaders and a team of developers would allow for rapid development, while meeting the needs of multiple teams.  Early adopters would drive the initial feature-set and help to drive its development.

Conclusion

My dream is to see the next generation of consoles and other platforms (PC, iPhone, Flash) all supporting a unified language.  I’m interested in people’s thoughts on this idea and candidates for which language to use.  It’s less about language features and just agreeing on a core language everyone can use to develop games and bring all developers onto the same page.

For some time now I’ve been asked by a few people to write up my thoughts on a coding standard. To me, coding standards are like source control, until you use them you don’t realise just how awesome they are. Coding standards are a requirement for large software teams, however even if you are working alone I’d recommend adopting at least a simple coding standard.Keeping code consistent and readable is helpful when reading other people’s code as well as when reading your own code weeks or months are it was written. In effect a coding standard is trading development time for maintainability time. I’ve found that the ratio of dev time to maintenance time grows from 1:1 on a small project to something approaching 1:∞ on larger projects.

I’d like to formally thank Greg for showing me the light on a lot of these points. I’ve spoken previously about pair programming and just generally mixing the experience level of developers to help the younger ones. I think that these kinds of relationships are invaluable for making great programmer as it’s something that you just can’t pick up from textbooks or coding by yourself.

As always, please add your thoughts and complaints. I think that just talking about these issues is a good step in growing as a software developer, even if everyone doesn’t always agree.

General Tips

1. Be consistent

This is the golden rule with coding standards in any language. Every other rule below is pointless unless there is consistency. If you completely disagree with all of my points below that’s fine, so long as you set out a standard, and everyone conforms to it. The only thing worse than a bad coding standard is not having one or having one that isn’t followed by everyone.

This can be an issue for some programmers as their ego’s get in the way however it’s vitally important that everyone follows the standard otherwise it will quickly turn into bedlam. This consistency should ideally cross both the programmer boundary and the project boundary. It will be much harder to have consistency between projects, however if this can be achieved, any programmer within the company can switch projects freely (even if only to assist briefly). This also increases efficiency on new projects when programmers who haven’t worked together already have this coding standard in common.

2. Get everyone involved

To get the best “buy-in” and to reduce friction amongst the team, it’s important to get everyone involved in the discussions. I’d recommend writing up the standard once “complete” and passing it around as the first draft. Giving people plenty of time to comment also gives leaders more ammunition when enforcing the standard. If people can voice their thoughts on the subject they are more likely to follow the standard in the future.

There is always going to be the inevitable ideological disputes where programmers won’t be able to come to a conclusion. There are really two options here:

i. Military style: The highest ranked programmer makes a decision, and everyone follows suit. This may be the only way to solve the most ideological debates but has the side effect of lowering morale.

ii. Politician style: Both sides put their case forward and the entire team (or key members) vote on which to choose.

Specific Tips

3. Curly braces – on the next line

if (condition)
{
}

This is pretty much the standard I’m seeing everyone use these days. There are some strange lecturers and Java programmers that keep the brace on the same line, but otherwise most people seem to have unofficially agreed to this. This has the added advantage of allowing the condition to be commented out quickly (using //)

Negative: It takes up less space having it on the same line.
Response: It makes code far more readable, and white space is free and should be used.

4. Always put curly braces in

The main reason for this is that it reduces errors in code such as a macro hiding the fact its multiple statements. The secondary reason is for maintainability. If the single statement becomes multiple statements it takes longer to update, and can lead to errors if people miss adding the braces.

Negative: It saves time to leave braces out.
Response: Saving time at the expense of readability is bad. If all conditions/loops have braces then the source will be far more consistent.

Negative: It takes up less space without braces and more code can fit on the screen.
Response: Fitting more code on screen is not as important as having error free, maintainable code. As desktop resolutions increase this argument holds even less weight.

5. Prefix members and arguments

class MyClass
{
int m_myInt;
};

void MyFunction( int a_myParam )
{
}


Firstly, adding these prefixes is NOT Hungarian notation. Rather than describing the type of a variable adding these prefixes gives context about what the variable is. This context is the key reason for adding prefixes. Prefixes make it easier to build a map in your mind of what the code is doing as you can quickly tell what variables are arguments/parameters, which are members and which are simply local variables. You can also add g_ to globals, however I’d be advocating the use of globals then J.

If m_ and a_ are too verbose then the alternative is simply appending m and a.

void MyFunction( int aMyParam )
{
}

Personally, I prefer the full prefix (m_) as it makes the code more readable, and it follows the convention of the first character of the variable name being lower case.

Negative: With modern IDE’s you can mouse over variables to get extra information
Response: Mousing over is slower than simply perusing code. The information given is usually just the type which doesn’t give context, it only gives further information.

Negative: It takes too long
Response: Again, readability is more important than saving a few seconds on typing

Negative: Underscore is hard to type
Response: Once you’ve been using it for a while it becomes quite natural. Also with tools like visual assist the underscore can automatically be added in for you.

6. Put modifiers (* and &) next to variable type rather than variable name

MyClass* myVariable;

This point actually goes against what I am seeing most people using in their coding standards at the moment. It also goes against what I was taught at university (whether that’s bad or not I don’t know). Before you dismiss it though, I recommend you actually sit and think about the alternatives and why you would use them. The modifier (pointers or reference) is modifying the type of the variable and therefore it should be placed next to the type itself. The negative to this is one I gave when first taught this, however after thinking about it I realised the error of my ways.

Negative: The modifier should go next to the variable name as it is misleading if you declare multiple variables per line. In the example below, the first variable is a pointer and the second is not, this is misleading.

MyClass* myPointerVariable, myNonPointerVariable;

Response: Declaring multiple variables on one line is really the exception to the rule. Should you be making a decision about based on the exception or the rule? If there are any modifiers like this, don’t declare them on the same line. The worst issue here is a bit of extra typing and more screen real-estate being used up, neither of which should be an issue. Having the pointer next to the variable name makes it harder to reader when skimming over code, particularly if there are a number of spaces (or tabs) between the type and name.

7. Create const on functions and function arguments where appropriate

Const correctness for variables is a bit like cleaning your teeth. It’s annoying to do, but everyone agrees that you should do it. There are three main benefits:

i. More descriptive code. A quick look at a function tells you whether it changes the state of an object, and whether it changes the state of any variables passed in.

ii. Faster code. Giving the compiler more information about constness allows it to optimize your code.

iii. Less errors. If a function or argument is const then anyone changing the function will get compile time errors if they do something the function was never intended to do.

8. Conditions/Loops should have a space after them

if (myVar)
{
}


This is the most readable way of writing conditional and loop statements I’ve seen. I personally recommend this usage, however the main reason for this point is to get you thinking about how it should be done. If you disagree, that’s fine, just make sure you remember point #1 and decide how you want your code to look and keep it consistent.

9. Camel case variables, capitalize classes and functions and full capitalize constants

I’ll finish up with an easy one. Most people agree with this standard but I thought I’d list it anyone. The best way to show this is with examples:

Variable:

int myVariableName; // camel case

Class and functions:

class MyClassName {} ; // camel case with capital first
void MyFunctionName();

Constants:

const int MY_CONSTANT_NAME = 5;

Below is a short list on how I believe managers can foster a good software development team.

1. Fire bad programmers (and don’t hire them)

I decided to start with the controversial one; however it’s one of the most important. Nearly every team I’ve worked on has had someone on it that should have been fired but the company just wouldn’t do it. There are many benefits to be made from firing the bad programmers, some of which aren’t immediately obvious.

a. The obvious one is that bad programmers add bad code. This in turn causes more work for the rest of the team, adds to maintenance time and pushes deadlines back. This also leads to software entropy where good programmers will be forced to work with bad code which often encourages other bad code.

b. They bring the morale of the team down. Any good programmer can pick a bad programmer after only a few weeks of working with them. It’s very demoralising to be forced to work with someone that is no good, particularly if they are getting paid just as much, or more than the good programmers.

c. They teach bad habits. Keeping bad programmers on gives new programmers bad influences to look to for support. By letting them stay on within the team, managers are basically saying that they don’t mind having bad programmers working for them. It makes it hard to foster good quality coding standards when members of the team are openly ignoring them.

The only caveat to this is mid-development of a product. It may be detrimental in the short term to remove bad programmers immediately; however this often turns into apathy where the programmer simply stays on to the next project or milestone. Look at the schedule and actually mark off when the time is right to remove them. Once this date comes around bite the bullet and get rid of them.

2. Give rewards

I’m surprised how many programmers when asked how work is going will mention certain perks or rewards they receive from their bosses. This can be anything from having a few days off after record profits to free food/beer/game nights once a week. One of the biggest problems with ‘working for the man’ is that there’s no direct connection between the quality of work programmers do and their rewards. This was one of the key points in Office Space and every programmer I speak to has had this problem at some stage in their career. The main purpose here is to tie the success of the company to the employee’s that are creating this success. It can range from profit sharing to simply taking everyone out for a big meal (with free drinks for those inclined) after meeting a big milestone.

In the grand scheme of things it doesn’t end up costing much, and the productivity benefits returned will easily pay the rewards back many times over.

3. Give good direction

There’s nothing worse than having a project that’s just aimlessly drifting towards it’s goal. There need to be set goals that the entire project is working towards as well as sub-goals for each individual team. Programmers are logical, methodical people and they like order in their lives. The more you can make the project’s direction fit in with this view the more the programmers will ‘buy in’ on the future direction.

Programmers will look at the project as if it were a program in itself. There’s a bunch of commands the team is following (create the UI), with conditions (if there’s time, add in flashy feature 53) and iteration (each milestone). If you can learn to think like programmers do and show the direction of the project in a way they’ll understand you’ll see productivity gains.

4. Be transparent

I touched on this in an earlier post, so I’ll keep this one short. Basically let the team know what’s happening within the company. You don’t have to give them every detail, but make sure that the important information is propagated. This can be as simple as a company newsletter or an internal website that has the news. Those who are interested can stay up to date and others who don’t care can just ignore it. People often worry about their jobs and not knowing what is happening can often lead to a drop in productivity.

Conclusion

I’d like to hear from people if they have other ideas or whether people agree or disagree with my list. As things move forward with the business we’re hoping to set up a software team in the near future so I’ll start posting on how implementing these and other ideas I’ve blogged about works out in reality.