Software Project Management - Split from 'Semantic Html'
- Thread starter Shamil
- Start date
Andy Huang
Well-known member
Real life experience tells me that trying to impose those "methods" does not work and only cause a team to fall apart... I've gone through and watched two different companies' products fall apart as result that... maybe a third one in the process, too, I just haven't check back often enough to know for sure. You're generally better off getting a dedicated team that knows what they are doing and are passionate about the project as opposed to trying to follow the book.
welshstew
Active member
^ This
A la, Kier and Mike. (maybe some more devs we know)
stevesant
New member
The best project management advice can probably be summed up with Release Early, Release Often (this goes for open source as well as commercial).
Specifically,
That seems to be exactly what Kier and Mike are doing. Hopefully they will keep it up.
Specifically,
That seems to be exactly what Kier and Mike are doing. Hopefully they will keep it up.
stevesant
New member
Of course. No one should release without careful planning, proper testing, etc. But with this alpha of XenForo, you are essentially following this principle, specifically the quote I cited. This isn't the only rule to follow, or even the right rule to follow all the time. However, keeping a product behind closed doors for too long, in the end, is good for no one. As a general rule, without any buzzwords or management speak, and not endorsing of any specific development process, releasing software and getting feedback from customers/users sooner rather than later is the way to go.
Sador
Well-known member
To be fair, when vBulletin said they'd introduce the 'release early, release often' tactic, I disliked it. And I still do. Upgrading your forum software is at the very least something that takes time and effort. Backing up, make sure your board is shut down, tell your users your board is going to be shut down, make sure addons / styling won't break and so on. Because really, in the end, are you willing to do that process every few days? I know I'm not. Nothing wrong with keep testing and gathering feedback, but it really quickly just ends up making life harder.
Joe Ward
Member
You can do the "release early, release often" thing just in a prototype instance - as being done here. That way, it places no direct burden to users to do repeated upgrade installs. Yet, they still get to experience and discuss the changes prior to continued iterative refinement (pre-official-release).
It's also easier to do in a cloud (SaaS) context where deployment is rolled out to everyone (or a selected segment) at once - and can be rolled back in the same fashion if any major issues are detected.
So RERO depends on the situation. It clearly works well here, considering xenForo.com as a prototype site for its future production release.
It's also easier to do in a cloud (SaaS) context where deployment is rolled out to everyone (or a selected segment) at once - and can be rolled back in the same fashion if any major issues are detected.
So RERO depends on the situation. It clearly works well here, considering xenForo.com as a prototype site for its future production release.
It was actually a comment on that very article.
wizzard
Active member
No one said release every few days, IB are only doing that because they keep introducing new bugs into the software that most of the time are quite critical.
Mark.B
Well-known member
I think it's worth pointing out that IB are not releasing "every few days", they've had a couple of, errm unfortunate instances that required a patch release, but "release early, release often" is talking of full releases, and for vB this is now about every six weeks, hardly unreasonable.
Not, you understand, that I have any wish to defend them, my views on them are well known but not for this board. However any criticism of them needs to be fair and factual or else it risks just being classed as "bashing".
Not, you understand, that I have any wish to defend them, my views on them are well known but not for this board. However any criticism of them needs to be fair and factual or else it risks just being classed as "bashing".
Sador
Well-known member
Read more closely. They stated they'd do this, which I didn't like. Later on, they decided otherwise (it's stated on vB.com somewhere because the idea would be more annoying than useful to most people. Later still, they changed the support policy so that release early, release often would kill support.
stevesant
New member
I think the meaning of Release Early, Release Often I intended got slightly lost. Yes, I could have instead said "using an Agile Scrum software development process with incremental releases and plenty of acceptance testing" (sorry for the poor attempt at project manager-ese), but this misses the larger picture and constricts development to something that doesn't work because it is full of buzzwords which have many interpretations.
When I talk about "early" and "often" (in a web context at least) I mean something like a beta/RC every 2-4 weeks and a stable every 2-3 months, but these numbers depend solely on the project and the team, and isn't right in all situations. In other contexts, these are going to be different, i.e. operating systems and iPhone applications will be released under different testing and circumstances. So to clarify the definition (that I use anyway), early: implies beta/RC, and often: any release (including these betas/RCs). Perhaps that isn't the exact definition from CatB, but in general, I find projects that follow that advice do quite well. How else can you know if your software is acceptable and working as intended if you don't get it to your users/customers? They are the ones the software is written for, after all.
Also, backward compatibility has nothing to do with "RERO." If an minor release breaks so much, there are probably larger issues with the overall design of the software.
Anyway, I just wanted to clarify my point a little bit. There so many factors involved in software project management. I just thought that this appeared to tie in with the current XenForo approach. I wasn't advocating any golden rule of software engineering/project management (I did say advice
).
Hope that made a little more sense.
When I talk about "early" and "often" (in a web context at least) I mean something like a beta/RC every 2-4 weeks and a stable every 2-3 months, but these numbers depend solely on the project and the team, and isn't right in all situations. In other contexts, these are going to be different, i.e. operating systems and iPhone applications will be released under different testing and circumstances. So to clarify the definition (that I use anyway), early: implies beta/RC, and often: any release (including these betas/RCs). Perhaps that isn't the exact definition from CatB, but in general, I find projects that follow that advice do quite well. How else can you know if your software is acceptable and working as intended if you don't get it to your users/customers? They are the ones the software is written for, after all.
Also, backward compatibility has nothing to do with "RERO." If an minor release breaks so much, there are probably larger issues with the overall design of the software.
Anyway, I just wanted to clarify my point a little bit. There so many factors involved in software project management. I just thought that this appeared to tie in with the current XenForo approach. I wasn't advocating any golden rule of software engineering/project management (I did say advice
).Hope that made a little more sense.
kmike
Member
Cool. Here's the discussion with that comment:
http://www.reddit.com/r/programming/comments/d062u
p.s. The "alert on quote" thing is working wonderfully!
Reeve of Shinra
Well-known member
Off topic a bit but there is an excellent book called "The Leadership Engine" by Noel Tichy and it goes into how winning companies create leaders at every level of the organization and those leaders are empowered to handle the situations that can come about. This is a direct contrast to the 'micro-management' that is typically seen and often joked about in movies like Office Space.
GE is a company that practices this and "winning" by jack welsh had some interesting stories about how we had to deal with crises as CEO. Its a great example of how LEADERS act and its a stark contrast to the failures we've seen in products that most of us are more familiar with.
Similar threads
