IndieZen http://indiezen.com Software Artisans Tue, 01 Mar 2016 15:36:18 +0000 en-US hourly 1 https://wordpress.org/?v=4.7.2 http://indiezen.com/wp-content/uploads/2016/02/NewLogo-150x150.jpg IndieZen http://indiezen.com 32 32 Early and Often http://indiezen.com/2016/03/01/early-and-often/ http://indiezen.com/2016/03/01/early-and-often/#respond Tue, 01 Mar 2016 15:33:14 +0000 http://indiezen.com/?p=69 [...]]]> While the Joel Test is a great way to determine if you have a good team, there are more things you have to do in order to be considered a great developer.

The Joel Test (excerpt from Joel on Software blog):

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before you write new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Other important things to add to Joel’s list of 12 are:

13. Do you have code reviews before committing or merging to the stable branch?
14. Do you have automated testing?
15. Do you eat your own dog food? (if possible)

In addition to this list of 15 things that identify great teams, I also have my own list that identifies great developers.

I call my list the “Early and Often” list, and they’re the things that software developers and development teams should not only do, but they should do them early in the development process, and they should continue doing them throughout the process.

In no particular order:

  1. Socialize
  2. Commit
  3. Branch
  4. Build
  5. Test
  6. Demo
  7. Document
  8. Ship
  9. Fix Bugs
  10. Fail

1. Socialize

Although avoiding the “design by committee” development anti-methodology is imperative, socializing is an important method for bringing other stake-holders along with the rest of the team. By doing this early and often, socializing ideas, product designs, and software designs allows other stake-holders to feel as if they’ve been a part of the process. Socializing product ideas can be tricky if you present an idea and your customers don’t understand it until they see it, but you don’t have to take it quite that far. Allowing users to vote on bug fixes and provide other general feedback on design decisions will help them feel included. The point with your customers (whether in-house or external) is to make them feel like they’re not being left out in the dark, and it’s very important to remember that a multiple-choice survey after the fact IS NOT the same as involving a stakeholder.  The same is true for architectural decisions and bringing in other developers that were not part of the decisions. For software designs, you do not have to socialize the design with everyone on the team, but you do need at least one or two others. After all, someone is going to have to review / bless your code.

2. Commit

With distributed version control systems this is a lot easier, but no matter which version control system you’re using you should be committing your code early and often. This helps you keep track of what you’ve done, and sometimes when you’re having a bad day you may just want to go back to a working version. I’ve also found that sharing these commits makes it easier for others to follow along with your progress and understand where you’re going a little more quickly. While this is a little harder to do with distributed version control systems, it’s not impossible. Eclipse and other IDE’s do internal versioning every time you save, which makes this task of committing early and often even easier.

3. Branch

Great software developers manage their source code the way a great sailor manages his boat. Everything has a place, and the place makes sense. New features belong in branches, every release should have a named tag or branch (depending on your version control system). Your main branch must always remain 100% stable, with no exceptions. Branching early will allow you to discard or otherwise shelve code that isn’t ready for production and more readily facilitates iteration and incremental releases.

4. Build

While a great team has an automated build system, a great developer will use this to his advantage. Even great developers don’t always see or understand the whole solution they’re implementing. The build step will help identify certain problems, allowing the developer to understand more about the solution. This step is more important when developing with statically typed and/or compiled languages, but using static runtime analyzers even with dynamic languages during the build step makes this step an important one.

5. Test

While the build step can identify issues that occur during compile and static code analysis, the test step can more quickly identify run-time problems. Even if you don’t follow a test driven design or a user acceptance test driven approach, unit tests, regression tests, and usability testing is extremely important. Unit tests and regression tests will help ensure that no matter how much entropy your system has, at least you know when you break something, and if done well testing can prevent many unforeseen side effects.

6. Demo

As part of user acceptance testing, live demonstrations of the software will improve usability, keep performance and stability high on the list of priorities, and keep your users up to date with features that are being developed. If you’re on the right track, this involvement with the users can improve developer/user relationships and keep the users interested and even excited about the product being developed. Using demos as a part of socializing ideas is also an important way of keeping less involved stake holders interested and involved

7. Document

Great software developers document as they go.  The source code provides a lot of this documentation, but any time there’s something that cannot be effectively documented inside the source, a simple little blurb in the README.md or published in a documentation wiki eliminates the risk of losing those all important tidbits of information.  Great developers write it while they’re thinking about it because it’s likely they won’t ever think about it again until someone asks.  It’s a lot easier to point someone to documentation than trying to explain in an ad-hoc manner.

8. Ship

Committing to shipping early and often forces developers to streamline their shipping process.  Whether you’re deploying a mobile app or a website or even a thick client, streamlining your shipping process so that you can re-deploy as often as you wish will allow you to quickly address issues, grievances, that annoying bug that slipped through.  It will also provide you with the mechanism to stay ahead of your competition by allowing you to quickly add that nifty new bell or whistle that sets them apart but didn’t really take much effort to code.

9. Fix Bugs

This goes along with Joel’s fifth point, which is to fix bugs before writing new code.  Fixing a bug as soon as you see it means that your software is always as bug free as it can possibly be.  If you forget some little annoying bug, that’s likely to be the very first thing a user finds… and trust me, they’ll find it.  Annoying bugs to you as the developer are critical to end users; your software only gets one chance, and if the “buggy software” bit is ever set by your users then it’s terribly difficult to get that bit reset.

10. Fail

Although it can be argued that failing often shouldn’t be a top priority, failing early is extremely important.  Great developers have bad ideas.  Everyone does.  If time is going to be spent writing code to implement a bad idea, it’s better to find out that the idea is bad sooner rather than later.  Great developers will write the bare minimum to get the idea implemented so that the stakeholders can play, touch, feel and determine if the idea is a good one or a failure.

]]>
http://indiezen.com/2016/03/01/early-and-often/feed/ 0
Floating Point Errors http://indiezen.com/2014/01/14/floating-point-errors/ http://indiezen.com/2014/01/14/floating-point-errors/#respond Tue, 14 Jan 2014 14:57:50 +0000 http://indiezen.com/?p=62 [...]]]> There’s a silly saying that we use in the IndieZen community:  When you’re trying to swim with a bag of hammers, it’s called a “floating point error”.

(ba dum bum)… and the crowd groans….

Ok, a slightly less corny saying that you’ve probably heard: “When the only tool you use is a hammer, every problem looks like a nail.”

This saying holds true of many developers, experienced and newbies alike. Typically a developer will learn one or more languages and eventually settle on their preferred language / platform as their “hammer”.

Some developers, no matter the number of tools in their tool chest, end up making up their minds that “this one tool” is the best, the ultimate, the last tool to rule them all. Once they’ve reached this point, it’s nearly impossible to get them to go back and re-evaluate the decision.

During the course of our collective careers, we’ve all let our prejudices get in the way of good decision making at one time or another. I’ve seen many examples of this during my career, but I’ll share a couple of stories where this really stands out.

One, the inspiration for my “A Fool Follows a Parrot” article, hated Sun and the (then Sun) license agreement for Java, and thus would never consider Java as a viable language, even in situations where it was actually more appropriate than his preferred language (which just happens to be Python). I wonder about his thoughts about Java now that it’s open source and we have multiple VM choices (and no more Sun, less restrictive licenses).

I worked with this particular developer on a web application. This was prior to Zope, Apache’s mod_python was in early beta stages, but Java for web apps was quite mature. Oh, the agony… luckily the web app was only a very small portion of the project.

Beyond prejudice, another reason developers always reach for their “hammer” is because they consider it a sacred cow.

A sacred cow is any sort of “default” answer used when you’re going through a list of decisions that should be made when solving a problem.

When you approach a problem with a preconceived notion of potential solutions before fully evaluating the problem, you’re likely to come up with a wrong or at least sub-optimal answer.

This problem is terribly difficult to avoid, especially once you’re stuck in a pattern of crunching through a whole lot of projects where each project requires (or at least benefits from) the use of code you’ve previously written. In this case, generally the same language and platform you had been using is the correct choice.

But, do you always consider that it may or may not be the correct choice?

If it’s a sacred cow, you don’t even consider it. If you’re a great developer, one without sacred cows, you think about it first, even if you know the answer is likely to be the same as your initial “default”.

The difference, and path to being great, is the fact that you think about every question without taking the default answer.

We had a great debate about this on LinkedIn. The original poster (OP) of the debate asked “Why doesn’t every game developer use C# to make games?”

He couldn’t understand why someone would want to use C++. As the debate continued, the OP dropped the conversation and another poster continued to argue that he would never use any language other than C# for game development.

He insisted that C# could do everything C++ could do.

It’s actually not a far stretch of the truth. Within a certain context and with certain projects, C# can pretty much do whatever most game developers want, especially if the target platform is a Microsoft platform.

Of course, I know a few other people that would claim Flash can do pretty much anything a game developer needs… especially casual game developers.

The problem with this is that all of these people are correct if you look at it from their viewpoint and if you’re tackling the problems they’re tackling, but if you’re looking at it from a “one size fits all” standpoint, there’s no single language or platform that provides the perfect solution.

There are reasons to use C# and .NET, there are reasons to use ActionScript and Flash, there are reasons to use C++ and the IndieZen frameworks, there are reasons to use Java and GWT.

Each of these languages and platforms have their strengths and weaknesses.

A great developer knows the strengths and weaknesses of many tools, languages, libraries, and platforms. He knows how to wield these tools professionally, accurately, and with skill. He will always choose the right tool for the job. Above all he avoids personal prejudices and sacred cows.

While having a hammer at your disposal is a great thing, not having a wrench, screwdriver, and some duct tape in your toolbox is a “floating point error”. Even if you do have a handful of tools, always reaching for the same sacred cow ultimately nets out to the same error.

Great developers have a variety of tools with which they are experienced using, and they always think carefully about the problem they’re tackling and choose the right one (or two or three… but I’ll save that discussion for another blog).

]]>
http://indiezen.com/2014/01/14/floating-point-errors/feed/ 0