@MarkR well, they can see why they needed them when they are implemented. but not a moment before that!

But there are probably nonfunctional things such as performance, resource consumption and robustness which are more difficult to quantify

When you put performance ahead of functionality, you achieve a top speed going from Southampton to New York, but without the ability to steer around icebergs

@MarkR like I want my server to server 1k connections, without using a single percent cpu usage?

this is a nice accent

In the real world, if you use < 1% CPU, then you should not even bother

I kind of map it the best with US English

If you can't load a box to 25%, maybe 50%, then you're not trying hard enough

I guess because of the movies I watched as a kid

I remember hearing it all the time

@MarkR I don't usually get stuck in those situations, some times there are some features which are added to the draft after the first implementation.

There are always features added at every stage, it is no excuse not to have some requirements

those added features usually give me a hard time, but then again there is usually a way to add them into the mix without slowing the system down

there are probably some engineers in your organisation, maybe managers, product managers, or whoever, who think they know what they want. They may be wrong.

@MarkR they always are :|

The trick is, not to allow the extra stuff slow you down too much, so you miss your release dates

you (project manager, or team manager probably) need to kick back on everything extra

or throw something else away

@MarkR I don't miss the release date on my self. the current game I'm working on is almost 5 months behind schedule :(

Be particularly suspicious of anyone who has a copy of Visio or Rational Rose

two were caused by me being sick.

@MarkR oh lord.

well that's a valid excuse

@Gajoo, this is a hobby game, right?

and about the others, managers told me I had to implement new features so I asked them to extend the project time

@ShotgunNinja nope

@Gajoo all you need to do is provide estimates, then you can ask them which tasks you can defer to make time

It is really bad to work in a team which frequently pushes back release dates to include more features

I find it is better to omit features to hit release dates

@MarkR well, they almost don't deny any task as long as I'm able to do it :( and there is almost no task that I can't do, so they simply extend the project time.

Otherwise you end up into the spiral of "just a few more features..." delaying your release so long that the senior management get bored and cancel the whole project

Someone must be paying for your time, and if they get sufficiently bored, they will cancel it

it depends what kind of software it is, what the release process is

but I think for SaaS, 2 months is pretty good between releases

it's a game, for both iOS and android

ios and android won't be released simultaneously though...

presumably?

the game was started around 9 months ago, and was set to be released 1 feb

I suppose for a game it's all complicated by the big amount of asset development

@MarkR don't know, I was developing for iOS when I began the project having android in mind.

Yeah well really depends on the assets teams

today I've finished working on android version while audio assets are not still complete.

Most of the projects I've worked on recently (= ~ 7 years) have had fairly small amounts of assets

I guess the android version will hit the market first.

suppose QA can still mostly work while audio assets are in progress

depends how critical it is to gameplay

@MarkR everything depends on the audio.

well the game is almost finished by now, except mostly optional features, a leader board implementation, and putting all audio assets.

Actually, I haven't heard of many games that require tight audio production, other than music games or The Hidden: Source.

@Gajoo what proportion of development time is before / after "code complete" ?

hidden-source.com

@MarkR I didn't get the question

^ fucking cool Source multiplayer game.

How much of your time do you reserve for bugfixing?

(and other such things)?

Is your game localised?

@MarkR localisation finished a week ago.

you have native-speakers testing?

and about bug fixing, the code is in playable state for something about 2 months by now, I've been adding minor features and fixing bugs till now

@MarkR native-speaker?

like myself? or the whole development team?

the game is going to be published in Persian and English.

Any tester, i.e. one tester native per language

no native tester for the English version (as far as I know) but still there are just a few texts in the game, without any voice. so I won't consider that to be a problem

NB I have worked on plenty of projects without a single native QA engineer

in some languages

Of course the more languages you support, the harder it becomes to have native QA in all of them

finding native English speakers is probably not too difficult

I guess right now it's more about bug fixing, more than anything. though there are just a few bugs needed to be fixed.

Well sounds good, I hope it is a success

Make sure you avoid scope creep and ship it!

but then again there are some features which I consider crucial but the mangers think they are not needed

like fixing time-step!

Fixing time step is good in principle, but if the game plays well on the target devices, I can see why they don't think it's worth it

or adding a content compiler, which will almost reduce package size for about %4 and enhance loading time by at least %50

Again, does it actually affect users?

package size right now is about 40MB, and by that content compiler it'll be reduced to almost 38MB.

the important thing is to ship it, and avoid introducing new bugs

a 5% decrease in package size, is not interesting to anyone

loading time is about 6 seconds and I expect it to be less than 3 seconds after that

it is not worth introducing even half a bug

angry birds takes more than 3 seconds to load on my phone

I think players will wait

but I don't like waiting my self. I gave up many games simply because they made me wait :(

If they've waited for it to download, they'll wait for it to start up

6 seconds is much shorter than the download time

@MarkR I guess you'll hit me, if I tell you that 6s loading time only happens once when the app is launching!

Right, so while they're playing, it's no difference

and 38M vs 40M? that's nothing

not worth delaying it or introducing bugs for anyway

@MarkR I've got to wait anyway, simply for audio assets to get ready :(

soo whats the debate

so any idea what else can I do?

Whatever you do, don't introduce new bugs

leave the code alone. Work on the next title

gajoo who is your music artist ? i need one for my game

Management must have a plan for what you do while waiting for audio assets, etc

work on the next release

@Dave I only know him by his name, and saw him only once or twice.

oh he not got a website?

In my experience, it is quite normal for developers to work on two releases at once

@MarkR I won't be helping them with their next project though

maybe you should be looking for a job then

@MarkR not really needed either.

any one see game of thrones last night ?

but still I guess there are some other visual features that I could work on...

some minor enhancing shouldn't be that bad right?

If it risks introducing bugs, yes, it's bad

If your release is late, you need to put more people on QA and fewer people on touching code

When I was on one late release, they took the entire department, moved us on to QA, and only let 1 engineer even touch the code

I was the only one touching the code from the very begining

In which case you should stop, except in the case of fixing critical bugs

If a bug comes in, you should triage it: does it block the release? If the answer is "no", then leave it unfixed :)

@MarkR and that's why I hate most of AAA games coming out these days

Fixing one bug risks introducing another one, but you're introducing it late in the cycle when it's more likely to be missed by QA

So the later you are in the cycle, the more critical a bug needs to be to be considered for a fix

Don't, of course, forget about bugs, make a deliberate decision not to fix them

what about creating tags? I guess the whole reason is to keep the stable code while being able to fix things without a fear!

You could fix the bug in a branch, or you could write a comment in the bug tracker such as "an easy way to fix this would be to..."

Anyway, I'm off now, bye. Don't forget to ship it. And remember not to introduce new bugs! Peace!

sooooooooooooooooooo

why did the chicken cross the road?

Wow, Zynga dropping 520 people.