Give me your best estimates...

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

patrikG wrote:
Hockey wrote:I'm not saying that "release early, release often" *can't* work but rather *doesn't* work...which if you look at all those open source projects on SourceForge...the truth is in the pudding. Perhaps it's an example of a little bit of insight being bad for you...I'm not one to say. Sure, If it's used in conjunction with other best practices, it might be successful, but rushing software leads to poor quality (It's a fact of life with anything really).

I wasn't comparing open source versus closed source, although proprietary software is often rushed too - just for different reasons.
I suggest you read the article I've linked to. As I said above, "release early, release often" doesn't work in a non-shared development. The reason why there are a number of stalled projects on sourceforge is that they have never reached critical mass in their number of developers. If they had, "release early, release often" would apply.
Your missing my point...

Most open source projects are rushed, as are proprietary projects. I've been developing for long enough that I can see the potential advantages of "release early, release often" but I also have enough experience to realize that is typically not the case.

What does critical mass have to do with it?

Even single developer applications should benfit in theory...the sooner you catch a bug the sooner you get it fixed, the less it reverberates across the entire system. That is undisputable. How does having only X number of developers less than critical mass, make this a moot point?
``Given enough eyeballs, all bugs are shallow''
That statement would apply to open source or closed source, multiple developers or sole developer...whether you have people looking at source code or just using your application...that is the point behind "release early, release often" as I understood it. The problem I see with that approach is that projects can use it as a crutch to avoid proper development techniques/design, etc...

Anyways, my point was not to dispute the "release early, release often" ideology (I can see it's advantages/disadvantages) but I'm sure as hell not going to focus on the fact that only 5 of every 5000 open source projects which follow that mantra suceed... :P

Yes, there are other factors which make or break a software project (open or closed) but it was a sales pitch not a convention. When selling propritary software, I'm not going to promote open source as an alternative, am I? Was I lying? Nope. More open source projects fail than closed source (in my experience - which is what I was selling - not yours - incase you care to argue that).
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Give me your best estimates...

Post by Christopher »

Hockey wrote:I explained that the disadvantage of rushing software to completion (such as the motto in open source - release early, release often) often leads to rapid application development, but unfortunately comes at the cost of poor software design. The larger software projects get, the more difficult it is in finding a replacement developer, the more expensive training becomes and the mroe likely your developer will just quit on you...
Hockey wrote:I'm not saying that "release early, release often" *can't* work but rather *doesn't* work...which if you look at all those open source projects on SourceForge...the truth is in the pudding. Perhaps it's an example of a little bit of insight being bad for you...I'm not one to say. Sure, If it's used in conjunction with other best practices, it might be successful, but rushing software leads to poor quality (It's a fact of life with anything really).
The first comment had the illogical non-sequiter "disadvantage of rushing software to completion (such as the motto in open source - release early, release often) often leads to rapid application development". "Rushing software to completion" is one practice. "Release early, release often" is a completely different practice that obviously leads to slower development because of the time spent on releases. "Rapid application development" is a third concept which can be achieved with numerous practices and is generally considered a positive by definition, because if you mess up then it's no longer RAD.

The second comment equates the number of projects on SourceForge somehow supports the statement that "release early, release often" doesn't work. There is not really much correlation between the two. Do all the projects there use "release early, release often"? Or only the successful ones? There are no facts supporting the statement.

And then there is a statement like "almost all software is not "designed" but rather starts as a simple concept and explodes into a messy hack" which is, in my experience, simply not true. I cannot, however, independently dispute your statement that 95% of applications you've worked on have become messy hacks.

I am not even clear exactly what and how you "aim to reduce that percentage to less than 15%"? You gave a mixed bag of things "technical support", "debugging", "patching", "productivity", "enhancements", "features", etc. which are scattered across the life cycle of an application. There is a subject to this discussion somewhere ... I'm just having trouble finding it ...
(#10850)
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

Kieran Huggins wrote:Some of the best developers I know work at Unspace, and they have this to say on the topic: http://unspace.ca/innovation/speak
That's a great speach. These guys obviously go for the release early approach. preferably release something after the first day of work :)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

I think you have been given the wrong impression of the idea...or have been fortunate like feyd.
Release early, release often is a core concept of XP - but hey, who said a release need be public? I think the failing factor is more that a) developers rarely practice RERO deliberately as part of a development discipline b) they have no release plan and c) they lose their enthusiasm for the project. SF is primarily evidence that open source is increasingly accessible, but prone to a massive failure rate due primarily to lack of interest.

I practice RERO all the time as an open source developer - even as an individual. You can grab anything I do open source from its public SVN repository and it will almost certainly be at least 80% functional. Usually I impress the importance of 100% functional for XP iterations (RERO in XP terminology) but I'm currently only intent on going that far with an open source project for PHPSpec (because frankly I am currently using it in small but paying projects and my time investment on it is an investment I'm certain will make a decent return - when I finish the damn feature list!). I know, for example, I announced SVN availability of PHPMock and PHPMutagen within mere days of their formation. The feedback I got back from those announcements was honestly invaluable. There is nothing worse then writing open source software and releasing LATE and INFREQUENTLY to the point nobody takes you seriously and you gather absolutely no momentum.
User avatar
nathanr
Forum Contributor
Posts: 200
Joined: Wed Jun 07, 2006 5:46 pm

Post by nathanr »

sounds to me like you can sum all this up by simply saying "you get what you pay for", in our world pay for = time, the more time, the better quality we produce..
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:And then there is a statement like "almost all software is not "designed" but rather starts as a simple concept and explodes into a messy hack" which is, in my experience, simply not true.
Your not even going to justify your claims with links to projects which are (what you consider) well designed - not hakced togather peices of yuck??? :roll:
Maugrim_The_Reaper wrote:Release early, release often is a core concept of XP - but hey, who said a release need be public? I think the failing factor is more that a) developers rarely practice RERO deliberately as part of a development discipline b) they have no release plan and c) they lose their enthusiasm for the project. SF is primarily evidence that open source is increasingly accessible, but prone to a massive failure rate due primarily to lack of interest.
Not me. :)

Anyways...while I agree...my point was more that it's taken to literally by many developers, especially those on SF. How many applications/projects I've seen which haven't even reached version 1.0. is an indication that the original developers are eager to release (for no other reason but to release)...especially when it's version 0.2.0 and hasn't been touched in 3 months...
There is nothing worse then writing open source software and releasing LATE and INFREQUENTLY to the point nobody takes you seriously and you gather absolutely no momentum.
Good point. Seems more important in open source than commercial software.
nathanr wrote:sounds to me like you can sum all this up by simply saying "you get what you pay for"
I wish. Unfortunately in software thats just not the case. The last commercial project I worked on cost 200+ USD per license/domain with small discount for every license purchased after that...

The software was some of the worst I've ever seen and buggier than...most software I ever worked on. Likewise I've worked on SugarCRM which is free and open source and didn't cost a dime. But it has an equally discombobulated source tree/architecture.

One was free and another cost money...both were poor experiences.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Hockey, honestly (and this is my last post on this thread): you will have to spend more time trying to understand what is meant by "release early, release often" if you intend to understand it. It's not about about rushing to a alpha/beta/RC or whatever release. Once you've got the methodology for high quality releases (SVN, unit tests etc. etc.) in place and you have a project you want other developers to join in you should "release early, release often" to keep building a community which benefits the quality of the project (amongst other things). E S Raymond's article is a piece on the social aspects of the open source movement not a manual for how or when to schedule releases.

A lot open source projects fail for a number of reasons, none of which have to do with "release early, release often". If the developers don't have the basics right, a project will, in all likelihood, fail.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:Your not even going to justify your claims with links to projects which are (what you consider) well designed - not hakced togather peices of yuck??? :roll:
You gave a fine example of SugarCRM, which you claim has a "discombobulated source tree/architecture." I am not exactly sure what that actually means as it is two different things munged together? Is a "discombobulated source tree" something you just don't like? I have worked with both versions 4 and 5 and never had any problem finding anything. It is not organized how I do it, but it is all broken down into fairly nice modules. And does it have a "discombobulated architecture"? Again, I have never found it confusing and there is a lot of code in that project. It is not done in the same way I build applications, but it is certainly understandable and seems fairly robust and full featured.

It is easy to complain about everything, and quite another to build a real and useful application. But none of that really has anything to do with you OP which was about methodologies. It is just going off on a tangent to avoid responding to the substance of you statements. Since your statements are all in the negative, are you saying that all development methodologies are crap? You are the one who said that RAD and RERO, and implicitly spiral model and Agile, only produce messes. What are you for? What do you support? What are examples of good applications?
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:I am not exactly sure what that actually means as it is two different things munged together? Is a "discombobulated source tree" something you just don't like? I
Haha. Touche!

That did sound like an oxymoron, so I'll re-phrase it: Discombobulated is the feeling I get when I browse a poorly structered file system. Better?

- If you think SugarCRM is well organized...lets agree to disagree. :P

- If you don't think the software could be improved and the overall performance increased...lets just agree to disagree again...

Cheers :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote: - If you don't think the software could be improved and the overall performance increased...lets just agree to disagree again...
I think all software "could be improved and the overall performance increased". The question is whether it is worth the time (and therefore sometimes money)? The Space Shuttle, a word processor and a website Contact Us form are three different levels of problems and deserve different levels of time, effort and quality.

The real question here is, given the same amount of time and developer skill, are there some methodologies that can produce better software than other methodologies?
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:
Hockey wrote: - If you don't think the software could be improved and the overall performance increased...lets just agree to disagree again...
I think all software "could be improved and the overall performance increased". The question is whether it is worth the time (and therefore sometimes money)? The Space Shuttle, a word processor and a website Contact Us form are three different levels of problems and deserve different levels of time, effort and quality.

The real question here is, given the same amount of time and developer skill, are there some methodologies that can produce better software than other methodologies?
1) I never said otherwise, but again our standards are maybe different. Does SugarCRM validate against XHTML on everypage? Does SugarCRM support true localization or just language tables? Does sugar have any hotspots in terms of application performance? I ask these and about an other 1,000 quality assurance questions when I evaluate a project. I'm sorry but sugar fails.

I grepped the source for the latest version and you know what I found? 6,600+ instances of the term "global" and something like 2800+ of the term "$GLOBAL" (case-sensitive). One of the first things I look for when I scrutinize an application are things like that, which I can find immediately with grep. No point is starring over the architecture or design for several hours when I can typically determine whether it's worth looking any further with a quick grep.

2) I think the real question is, how professional are you (as in the reader not you)? Personally, I consider myself to be the best of the best (and I hope you do to). I've been at this professionally for a long time and inspired by software/programming for even longer. Listening to various other profesisonals over the years talk about quality and standards, only motivates me to meet and exceed what the next guys does.

So, although the question on whether methodologies come into play is accurate, it's only part of the entire quality assurance pie. :P
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Again, an application like SugarCRM has many things that it can be improved -- and it is continuously being improved. But that's not a total failure as you seem to imply, that's just reality. As I said, there is no application immune to improvement. Your example of using globals is simply noting piece of programming wisdom that using globals can be the source of side-effects, but the existence of globals does not mean that there actually are problems. Globals can be managed (and are in probably billions of lines of code today). The bottom line is that SugarCRM is very useful and widely used software. It is fairly well designed, organized and coded, and it's improving. But the fact that it is the useful is the most important part -- that's the point of software.

And no, I don't consider myself the best of the best, or even anywhere near close to that. Which is why methodologies and practices are important to me. They are tangible things that have a direct impact on the quality of the software I produce. I have no way of measuring "how professional" anyone is. That is a subjective assessment. But I can learn new methodologies and practices, and see the improvement in code quality and time spent over previous projects.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:It is fairly well designed, organized and coded, and it's improving
Relative to what exactly? You personal experience I would guess. In which case, I don't think your understanding where I am coming from. Most projects I have worked on are like SugarCRM. If your not in need of more experience working on projects like that, maybe you need to spend more time...cause I tell you what. 10 years of workign with globals, more than acceptable code duplication, horrible comments, poor file structures, etc...

While I wouldn't say it's left me winded...it's certainly left me tired of the same old thing, when my spidey-sense tells me it could be better.

You missed my point when I said I consider myself to be the best of the best. It' more about not letting deliberate errors ocurr than boosting thy ego. :P

Here is how I see it: Complacency is a real killer (especially when your a pilot - the path I originally persued in life). Confident people are allowed to fail. Complacency sneaks up and murphys law bites you in the a$$. Sometimes it's a lesson learned, othertimes, you become the lesson. Cocky people can't fail!!! Their pride constantly reminds them of the fact everyone is waiting to watch them fall.

I bark like I'm the best, because it reminds me to always be my best. I realize to error is human, but it doesn't mean I have to accept making errors or mistakes which I know are avoidable. The statistic goes like: 80% of aircraft related accidents are pilot/human error. Meaning, it could have been avoided. In programming, 100% of errors are human error - meaning they could all be avoided (unrealistic perhaps). If your average developer spends 50% of his/her time fixing mistakes they made because they jumped the gun a little to soon, then I'll be damn sure that I only spend 25% of my time doing the same thing.

Maybe I'm just competitive (no secret there)...but it's usually people who want to win that do. I can't remember ever watching the olympics and hearing an athlete say: "Man that was a great race and I didn't even really want to win".

Take from that what you will, the whole point of this disscussion was to see if anyone shared the same passion/experiences as I have about software development and possibly had the desire to at least make a serious effort to make things better. Infact not just slightly better, but way better.

In the T&D forums I have seen you expose the evils of GLOBALS and other bad design techniques countless times (infact you've even influenced my choices in the when I thought you were right) and yet here you are challenging everything I say like you incorporate these practices in your own designs and are defending your own bad choices...what gives?

Do you follow OOP practices and principles like OCP? Do you not utilize dependecy injection as required? Do you not favour composition over inheritence most of the time? Do you not follow your very own advice you preech in the forums??? The fact is, if I presented the code in SugarCRM on the forums and asked for opinions, you'd be all over it like hotcakes.

You've really spun me 360 here. You are one of the few I figured might agree with me on the amount of poor quality software currently availble (from the developer perspective anyways). Maybe your defending my accusations, because you have some sense of humility that I don't share. I can appreciate that...being humble and all. The fact is, humility is not a one way street. You are not supposed to just be humble around humble people, but retain that humble opinion around cocky people as well. Otherwise your not humble or cocky, but in my opinion, confused.

While you are right in saying SugarCRM is useful (I use it in-house it's why i used it as an example cause I know it well) that was not the point of this disscussion. I thought I made that clear in the original post. In such a competitive market, I need an edge. If I can match a product feature for feature, but I do better, faster, safer & cheaper on every level of software development, the idea is, the software will sell itself.

patrikG: I get the idea behind RERO. Really I do - it's not rocket science. ;)

Your either missing my point or trying to make yourself believe, I am so ignorant as to not see the benefits to RERO. My point was, most projects use it as a crutch. Just get the code released and the community will find and maybe fix bugs.

That is that complacency effect I spoke of above. It's pure laziness most of the time. While I am sure there are some projects who nail it right on...those are the minority, not the majority.

I'll give you a tip. When your selling something to a potential client, the last thing you want to do is hilite the benefits of your competitors products and focus on the negatives of your own - which is what you seem to expect I should have done. I focused on the fact that most software is indeed rushed (SugarCRM initial release took only 3 months) and happened to use SourceForge as an example, because *most* of the projects on there are incomplete, of poor quality or total failures.

Was I supposed to focus on the handful of projects which implement RERO successfully? I would have, had I been promoting them...but I was selling something completely different and in this case, the open source alternative is of poor quality...case in point.

Cheers :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I am not sure how to respond to the whole attitude and cocky pilots can't crash part of your post ... so I won't ....
Hockey wrote:Take from that what you will, the whole point of this disscussion was to see if anyone shared the same passion/experiences as I have about software development and possibly had the desire to at least make a serious effort to make things better. Infact not just slightly better, but way better.
Maybe that is your point now, but here are the questions you asked in you initial post (with my condensed answers):
What have your experiences been? good
Would you agree? no
Would you say I've had a bad experience? yes
More importantly, if you feel my experience has been poor and yours was not, would you mind explaining what you feel made the difference? my emphasis on practices and methodologies vs your emphasis on professionalism and attitude
Was it software design/principles that made a difference and would you care to give me a reference (name, email and quoted statement on what made the difference?)... all the standard references, but it is true openness to the ideas that is, to me, the hard part
Hockey wrote:In the T&D forums I have seen you expose the evils of GLOBALS and other bad design techniques countless times (infact you've even influenced my choices in the when I thought you were right) and yet here you are challenging everything I say like you incorporate these practices in your own designs and are defending your own bad choices...what gives?

Do you follow OOP practices and principles like OCP? Do you not utilize dependecy injection as required? Do you not favour composition over inheritence most of the time? Do you not follow your very own advice you preech in the forums??? The fact is, if I presented the code in SugarCRM on the forums and asked for opinions, you'd be all over it like hotcakes.
I think if you go back, you will find that I point out both the benefits of best practices (like not using globals) and that if you are aware of the consequences of a decision then almost anything can be managed by a competent developer. There is a difference between unknowingly and knowingly doing something potentially dangerous.
Hockey wrote:While you are right in saying SugarCRM is useful (I use it in-house it's why i used it as an example cause I know it well) that was not the point of this disscussion. I thought I made that clear in the original post. In such a competitive market, I need an edge. If I can match a product feature for feature, but I do better, faster, safer & cheaper on every level of software development, the idea is, the software will sell itself.
Code quality is a component of the cost and the time to develop/maintain software. But your initial post was a pitch to a client and for clients usefulness is most important thing. A couple of the benefits of RERO are earlier delivery of useful software to the client and earlier delivery of knowledge about the design to the developers. The trade-off of initial code quality for those things is a reasonable one in many cases -- it is "an edge." You don't say how you "do better, faster, safer & cheaper" other than with a lot of moxy. RERO, Spiral, Agile, etc. actually document practices that can help.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Hockey wrote:Anyways...while I agree...my point was more that it's taken to literally by many developers, especially those on SF.
Again, it's arguable. RERO is largely unintentional in open source. It's just a natural inclination of developers to release something with minimal functionality ASAP because it's free, the cost of criticism is extremely low, and it piques interest by others. I've worked on projects (doesn't take a genius to find them) which have quietly almost died after numerous early releases plagued by incompletion, bugginess and the practices of a PHP programmer in the early 2000's (the good old days when I would have asked remarkable questions like how to get the values from a form in a PHP script, pleez ;)). Some of them are still used today by a small number of people. I have an email here dated a week or so ago from a fan of one project linking to his svn repository where he's busy hacking away on one of them. Remarkable really. He even claims to have removing the register_globals requirement near the top of his todo list. You'd be surprised at how not dead some of those SF projects really are.

I know for a fact those releases were not formal RERO - they were powered by a small community of people who wished to test new versions as often as possible. Back in those days, asking any of them to use subversion/cvs was a stupid idea, so I made releases every few weeks. Informal RERO is just a societal norm in open source - you end up doing it one way or the other for any number of reasons.
Post Reply