Shared Draft: Prototyping and Code Quality

[Timo Heinäpurola]

Hi all,

I haven't had time to write for some time now, but here's a new entry: http://www.altdev.co/?p=31053&shareadraft=baba31053_5350e31c4d548

What do you think?

-Timo

[Joseph Simons]

Some specifics:

- This sentence is awkward for me to read: "The method relies on quick iteration to lay out functionality and testing it out to quickly cut a feature that is not deemed worth implementing and add new more promising ones."
- "This stage of development consist of a number of very small" - should be "consists"
- "You know you will never get clearance for such a large scale operation unless there is no other option available." - I am not quite sure how this sentence fits in with the rest of the paragraph. I would suggest removing it or clarifying it some.

- With the self reviews, it is also useful to make sure you removed all debugging code (or clearly commented any that you are leaving in).

Overall, I think the article reads well and is useful.

--
You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Oliver Franzke]

Nice article Timo!

I would curious to hear your thoughts on how to deal with the situation when you are asked to simply clean up the prototype rather than rewriting it (despite the initial agreement that the prototype is meant to be thrown away). I ran into this many times in the past and so I would be interested how other people are trying to convince the project lead or producer that prototype code generally isn't great for the final product.

Oliver.

[Shawn Kirsch]

I agree, I'd been wanting to read this one for a few days now.  

I really dig it, I think you hit on all the major things I felt should be in there.  I do agree with Oliver as this situation does come up every now and then.  Maybe a good addition to the article.

Shawn Kirsch

www.shawnkirsch.com

[Alex 'darbotron' Darby]

Hey Timo

Overall this contains a lot of solid advice that correlates well with my own experiences.

My first point of feedback is a very minor point really but, since my wife is an English teacher, grammatical pedantry is my stock trade ;) 

There is at least one case of misuse of apostrophes - specifically you have "it's" where you should have "its"; "it's" is a contraction of "it is", the word "its" is a 'possessive pronoun' - e.g. "A bird flaps its wings whilst it's flying". 

Please accept my humble apologies for over-labouring this point :)

Secondly, like Oliver & Shawn, I'd love to see the question of how to clean up & live with prototype code addressed.

On the majority of occasions where I have been involved with the development of a game prototype we have ended up being forced to take some or all of the prototype code on into the production code base (e.g. by time / budgetary constraints / bad management decisions ).

My personal take on mitigating this is to define a "minimum acceptable level" of software engineering principle that should be applied even when writing prototype code. I've found the best question to ask of any architectural decision taken during prototyping is "can we live with this code if we need to?".

I was going to write down a load of rules of thumb for this, but I stopped because it started to get out of hand - am happy to share what I typed if you want it, but was worried this reply was getting a bit too wall of text-y :)

A site that I find super good for this sort of general "how do I write good quality code" discussion is: http://pragmatictips.com/; this beauty is one of my personal favourites "restrict mutability of state": http://pragmatictips.com/74.

I've also found that the majority of genuinely far reaching architectural decisions can be cleanly isolated into either engine or framework code which should be game agnostic. This makes a massive difference to the issues & risks of living with prototype code, but is also contingent on the maturity of the technology you have access to.

Personally, I'd be inclined to emphasise early peer review a little more - in my experience early peer review is the most valuable, ideally before writing any significant amount of code for any given task, because it's likely to pick up big problems before they happen rather than after a peer has implemented a system that has serious issues.

Hope some of this is helpful :)

Alex

p.s. Another typo I spotted is "wise versa" instead of "vice versa".

[Alex 'darbotron' Darby]

Bugger! You've already posted it.

Ah well, next time I'll be quicker ;)

Alex

[Joseph Simons]

You can still edit a post after it is up. So minor typos like you pointed out are still worthwhile to look into fixing :)

--

[Francisco Tufró]

I've been in the situation of having to convince two different leads about this.

1) The guy was strongly immerse in a feeling that no matter what code you have, enough enhancement iterations could lead to the same product.

2) The guy was not sure about his opinion on throw-away prototypes.

It was obviously easier to convince guy #2 about it. My opinion is that the prototype served to quickly tackle the most riskiest assumptions about the project, and the knowledge gathered during that period of research makes the final version easier to implement; since you've solved the problem once, the second time you'll do it better...

There was no chance on convincing guy #1, mostly because he's right. Working on the project proved it, it's true, you can always iterate until you've got what you want, but in my opinion it also proved to be slower.

You may want to notice this, speed is important too, but in the end examples are better than thoughts.

What I'd do in that case if I have to do it again.. I'd ask to perform A/B Testing to help the lead decide. Re-implement some part of the prototype and work on top of another, and see what happens.

Hopefully I'd re-implement the final version quicker than the incremental and iterative approach.

Francisco Tufró

Indie Game Developer / CSD / Musician

in...@franciscotufro.com
http://franciscotufro.com

http://stillbeingsimple.com

http://simplex-engine.com

[Timo Heinäpurola]

Hi all,

Thank you all for the feedback! I'll go and fix those pesky mistakes :)

Prototyping and code reuse:

Of course it depends on what system you are prototyping, whether or not it's even possible to reuse code from the prototype without having to rewrite it. Generally speaking, as I pointed out in the blog post, prototyping usually focuses on a very small part of the application and it might thus be enough to implement it using a totally different architecture than the final application. For instance, you're building the next Halo with insane requirements for visual quality and you would like to investigate player control mechanics for the game. It might make sense for you to work on a custom engine due to those technological requirements but player controls can easily be tested in Unity due to it's insanely high productivity. In this case I don't see any lead forcing you to share the code if your own engine is not a Unity copy... ;)

In the more borderline cases it might become more complicated. There are so many types of leads as there are leads on this planet and every such person naturally has his/her own view of the world. But I think it's a sign of a good lead if he/she is willing to listen to good reasoning. You as a developer also have to be honest about it. In some cases the prototype is just so simple that you can copy/paste most of the code. You have a single method that does string conversion, for instance :) Such code can most likely be easily cleaned up. Anyway I would still copy the code over and not start building on top of it so as to leave the prototype as a reference (at least tagging it in the version control system, if nothing else).

My recommendation is thus to give a comprehensive estimate of how long it would take to base the actual implementation on the prototype and also give the same estimate for rewriting it. Couple this with a description of what both options mean in practice. If your lead still insists on the "wrong" choice then I'm afraid it's also his/her responsibility if it goes wrong... One thing a good lead should always remember is that a single application can be implemented using many types of architectures. The architecture should be designed so that it makes the whole application possible and satisfies the required nonfunctional requirements. Often such architectures force you to work in ways that might not be optimal for quickly creating a new prototype but they are much better at lowering your workload in the long run (plugin and IoC architectures, for instance). Often code leads will understand if you just describe the different tasks involved in both options but producers and project managers might need the estimates since they are usually much less technical. Be honest and thorough. Don't expect them to understand the details as well as you do.

Hope this helps!

-Timo