EVE Information Portal

I appreciate the want to deliver, and make grand promises. But there is -no way- you're -ever- getting down to 4 week cycles. 10 weeks is a reasonable achievable goal.

By even uttering 4 or 5 weeks your setting yourself up for a miserable experience with your customers. Tell us 10, and if you do get things done earlier great! But with an expectation of 4 weeks we're either 1) not going to meet it at all and get nothing (you'll tell us we need more iteration, code, or testing) or 2) just end up pallet swapping colors on ships and producing seriously weak development efforts.

I work with developers every day, I get that you want to deliver. I appreciate that, and I think you guys do a bang up job. Let the managers set the expectations to 10 weeks and communicate that. Don't set yourself up for failure by stating 4 or 5 week "hopefuls" you'll never -ever- hit that mark.

Under-promise, Over-deliver.

This is largely irrelevant, one team or fifty, there's going to be bottlenecks in the process either in testing, iterating, or QC'ing that will prevent this from happening

The point is management of expectations, and delivery of a quality product. Manage your customers expectations to something that isn't going to stress your team (setting release schedules to 10 weeks say), and gives you time to actually deliver something of value, quality, and desire from the client base.

There are a couple of ways that this series can fail as I see it.

First, by making these kind of statements and saying that you're aiming for 6 weeks cycles. This isn't going to be sustainable, as such every six weeks when you miss these deadlines, your customer base is going to get upset, locking you into a perpetual "we said 'about' " cycle, and getting into semantic debates about what "soon" means. Those arguments if you're having them means management has failed to effectively communicate a message. You can address this by pushing your deadlines way past when you expect them to be done, giving you plenty of flex time. And if you deliver early, great! Throw it on test, and get a solid testing period out of whatever feature you're proposing. (This also generates hype surrounding things as the customer base feels more involved in the process)

Secondly, release of anemic, under-thought, or bug filled releases. If you try to push to a 6 week cycle, then you end up locking into a position of "deliver whatever you can", which means cutting corners. Dev's will work on features that they like, pushing off the "easy stuff" since they believe they can get it down and then come 0 hour they 1) get a bad attitude because now they have to crunch and didn't get to do the thing they like doing, and 2) rush the code and produce anemic results.

Just be careful guys, this is from years of experience working with a development team. I firmly believe that you guys do great work, and while I can't speak to the specifics of your work environment the 5 companies I've worked with doing this type of work the biggest problem has always been 1) letting a developer set a timeline and 2) management not effectively harnessing resources to hit the timelines once they're established.

Good. I'd much rather see an ongoing series of smaller, well thought out releases, than the less frequent disasters that have been done in the past.

Plus this gives me something to look forward to on a regular basis. And if a release is a little disappointing, it'll only be six weeks until the next one that might be more interesting.

"The new model in action - industry features planned for Kronos moved to the Crius release"

sounds more like:
"The new model in action - Delivering you content one month late"


i just hope this new release system will not be an excuse for every delay or poor project management on new features.
Still i understand industry is a heavy, risky one!

I happen to work in software development for one of the world's largest software companies.

With 25 years experience in the industry, I've seen a lot of changes.

Once upon a time:
Functional Decomposition: Start with a problem statement, break it down into all the components that need to change and think through all the ramifications. The entire team was involved in this analysis and design process including product managers, developers and QA. The output of this would be a detailed set of requirements. Developers would then go off and work on coding necessary to meet the requirements while QA developed test plan, test cases and test data to completely test the requirements. When Dev was complete, QA would test the requirements(acceptance test), plus all previous requirements (regression). And once a year to two-years, updates would be released, as complete solutions that actually worked.

BUT, that was too slow and too expensive. The industry is rarely dominated by the best product. First to market usually wins.


So, first to go was the A&D. It started with Rapid Prototyping. Instead of starting by thinking through all the ramifications of the changes, start by coding, and then figuring out the requirements as you go. You were supposed to use the prototype to figure out requirements, then throw it away and start over, but no one actually did throw away the prototype.


So, we stopped pretending we would throw away the prototype, and just change the name fo Agile. Oh, sure... text book agile, there is still a A&D phase, it is just done by Product Management while the devs and QA are off working. This dream of Just In Time Analysis and Design was never actually realized, and requirements went away in favor of high level use cases.

"As an industry player in EVE, I want to have less meaningless complexity and more meaningful choices". This kind of epic is broken down into stories... "Convert waste = need * 0.1 / (ME + 1) into 1%-10% reductions, similar to skills". "Remove fixed number of S&I slots and replace with a system based on usage." "Remove remote research to make meaningful decision on where to research." "Cap return from reprocess, and make it possible to compress ores high sec so it can replacemineral compression via build/melt."

While these stories may sound great at first glance, without the full A&D process, thinking through ALL the intended and unintended side effects, you have the opportunity to go horridly wrong. And, you don't really know how you're going to do it, so when you hit a snag in the middle of an iteration, the tendency is to go with whatever solution is the least work, so you can close stories and hit your trajectory numbers.



So, after you've started delivering garbage (because you stopped thinking it through and designing it well) on a regular 6 month cycle, the next big idea ( we're at this point at my job right now) is to assume the problem is that you're not delivering often enough. Oh, if we could have just had an extra month to slap some more hacks on top of the horrid, not thought through changes, life would be better... but we can't slip because customers do not want to wait a whole 6 months. So, let's just ship one a month, or every 6 weeks. That way, we can ship what is ready and not ship what isn't ready...

Well, the thing that has to go in that cycle is the regression test. Hack together some changes, acceptance test those changes in isolation, then ship. Cross your fingers and hope you didn't accidentally break something else.



Software, like most design, has always been a triangle, with the points being fast, cheap and good. Whenever you move closer to one point, you move further away from the others. You want fast and good, it is very expensive. You want fast and cheap, it is not going to be good. Want really, really good, then it is not going to be fast or cheap.

Whilst this has the potential to be an improvement, I can't be the only one wondering whether things really WILL change regards shoving broken/ill thought out things live, because it's due now, or if there will actually be more listening to feedback and acting on it. Partly the problem has always been a seeming lack of willingness to listen to any feedback no matter how constructive, but now that the half-excuse of not wanting to hold something back because it'd delay a whole expansion is gone, we can see even more clearly who really wants to listen and act on feedback from sisi when just about everyone is screaming "this is terribad, you've gone the wrong way" or "it's a nice idea, but x,y and z really need rethinking/tweaking because :reasons:", and those teams that will be willing to go back and redo stuff when they screw up (however well meaning their first try may have been).

tl/dr I hope the balance comes down right between being concerned about vaporware projects, and pushing junk.


Also to those concerned about the 6 weeks target this will depend how resources are allocated, if near everyone is working on large, long-term projects with a small team or maybe 2 doing stuff with quick turnarounds we could well end up getting to 6 weeks, and the team or 2 working on 'easy' stuff have a handfull of small changes if anything that whilst nice to see live people will wonder if it was really worth bothering to ship, conversely if there's a greater number of people working on shorter stuff then there should be a steady stream of things being finished within each release timeframe, as each time a different groupd of people will have something ready, frankly we simply cannot know how resources will be divided up, or even exactly how much time a 'easy' job takes with the joys of EVEs legacy code.

**Also can the post-eating monster in the forums please be killed one year, so glad I remembered to copy before hitting the damn post button

Why not? Of course we are going to be looking at what our overhead is, but not all teams will be participating in all releases so if their plans are staggered (and even multiple things that have a different timespan within each team), then having a release more often than every weeks 10 weeks is quite conceivable.

Only a very slight correction: Some teams use 1 week sprints, others use 2 week sprints. Otherwise, right on the money.

Any word on if all changes will get put on sisi first or if like the tool tips changes and several other things that got dropped directly onto TQ without testing be the norm?

why is there never a button to not use a "feature" ?

If you guys pull this off, I will be very excited. Again, not saying that you can't, I'm just always suspicious when something like this is floated by dev people.

In almost 15 years of working with development teams(again I'm not a dev) I've seen maybe 2-3 actual projects launch in an acceptable manner when major overhauls to their release scheduling and team functions have occurred.

I do really hope you guys can pull this off, and please believe me when I say that my concern really is only for you guys. If these 6 week cycles turn out anemic products, or worse, just get the whole "we need more time" stamp, you're going to end up spending more of your time here, responding to customer complaints about why you either delivered a poor product, or didn't deliver at all, instead of coding up the next cool feature.

-Still think you guys do great work, and really am rooting for ya.