Having conventions is lean

In this article about how software was/is written for space rockets one particular sentence stayed in my mind:

“… you can’t have people freelancing their way through software code that flies a spaceship, and then, with peoples lives depending on it, try to patch it once its in orbit”

I interpret “freelancing people” as software developers who do not care about things such as conventions, best practices and principles that a team or organization has set up. For example instead of following a common coding guideline they continue to do their own thing which in their opinion fits best. From a lean perspective this is actually nothing more than creating waste because it causes constant friction with the rest of the organization. As a result others have to use their time arguing with “freelancing developers” about their code in reviews, they need more time to understand their work or might have to rework it. It becomes tedious and frustrating for them having to deal with this situation which in turn is not good for the entire work atmosphere and can result in second level waste such as less communication. Instead of implementing the next feature together, people are stuck in senseless dicussions. Having this in mind it’s obvious that establishing and following conventions, principles and practices does not result in waste but actually helps to avoid it and increases efficency.

Flattr this!

The Buggs are released – or how to make a game in your spare time

It’s been quiet here in the last 2 years…

For the last 2 years I have been renovating a heritage listed house and worked on our game called “Buggs” and released it on Google Play and the AppStore! (http://u2p.co). Making and especially finishing such a game beside having a fulltime job, family with little children and friends ist not an easy task. Actually it requires a lot of discipline to sit down at the computer again after a full day while everyone else is gone off to bed. Here are a few things I have learnt from making Buggs:

  • Realize whether this will be just a toy project where you’re trying things out and learn new stuff or whether you want to get something done. The following are learnings from the latter goal. However you’ll still be able to learn new things. It’s just not the focus and unless it comes with the project no extra time should be invested.
  • Involve your family and tell them what you plans are. It is easier to build on understanding and maybe support than being confronted with incomprehension and intolerace.
  • Dedicate and reserve timeslots for one and only one thing and stick to it. For example: It it is completely unproductive to run back and forth between playing with your children and trying to fix a bug in your software. It’s much more efficient to dedicate one continuous block of the time spending with your children and another one fixing the bug. Make clear to everyone when you need to concentrate.
  • Take yourself time at the beginning and learn and understand the technology you are working with first. Since you only have a few hours to spend on the project each week you might be tempted to dive right into the work without fully understanding the technical environment in terms of patterns and practices. It will pay off to professionalize yourself first and prepare a proper toolset. Including well-known best practices like a version control system, CI or a common network share.
  • Run your project together with at least one other person who is also fully committed and determined as you are. It’s hard if not impossible to work on, focus on and finish something over such a long time when you are alone. Partners will motivate and help each other: When your graphics guy invested time in new 3D models s/he will certainly insist on that you spend time on providing the necessary game logic and vice versa.
  • It’s your spare time and a hobby but try to come up with at least a rough plan and timeline. The Buggs started of with a small idea and we refined and redefined that idea basically every month after playing with the latest build. While it is okay to have this feedback loop and after all it’s still a hobby but this approach can be very time consuming. It’s better to sit down and plan on what you want to achieve in the next 6-8 weeks and on a coarser level in the next 6-12 months – at least roughly. This also helps everyone to stay motivated, especially when some milestones are achieved. After all, you know, when you’ve got endless time you tend to take one’s time.
  • Prioritize and look on the return of invest for everything you do. Again, since you have only a few hours each week, it’s harder to move forward than it is in a fulltime job. Don’t get worked up on details, don’t do things with low value or worse reinvent the wheel. Rather, get an early alpha/beta version out to your friends and ask for feedback. (Don’t worry. It’s very unlikely that some of them will “steal” your idea and place a copy on the market before you’ve published the original. That did not even happen to Minecraft.)
  • Be prepared to invest serious time into marketing once your project is done. It’s hard to build a product, it’s even harder to build an interesting product and it’s very hard to attract attention.

Flattr this!