Re: [Ilugc] software development practices
On 06.06.2012 12:09, kenneth gonsalves wrote: > not necessarily. In the first place, as far as I know, developers > rarely > package their own apps. when requirements are gathered, seldom one has info as to who will develop it. developers are rarely exposed to the requirements at the initial stages. neither are they too interested to test their code & they leave it testers. most of them even believe that testing is something beyond their fundamental responsibility. after something is reported they do come forward to fix it. :-) -- Amachu ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Tue, 2012-06-05 at 21:45 +0530, ஆமாச்சு wrote: > > Anyway if you have some experiences in these, please share. > > (Koha has paid developers too) > today a popular Open Source Software would mean that it has to be > packaged & made readily available as binary for installation atleast > in > two family of distros - debian & fedora. not necessarily. In the first place, as far as I know, developers rarely package their own apps. The packages are usually built by 3rd parties. Also a lot of apps do not have binaries - like django. Also since deployment in a framework like django is usually through virtualenv or buildout, the rpm/deb cannot be used. I have seen people trying to use the packaged version of django in Fedora and Ubuntu and it has been very frustrating for them. > > post development - building them to get the binaries for various > architectures & taking them to repos/ maintaining there or under > one's > own repo can be given some priority. > > -- regards Kenneth Gonsalves ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On 06/05/2012 04:01 PM, kenneth gonsalves wrote: > > the only one I am familiar with is django - they fix a rough date for > release, but release when it is ready. They have rough list of features > for release, but those features get included only if someone gets them > ready. Same with translations. As for bugs, those described as release > blockers are fixed before release, if someone fixes others, they get > included in the release. In a purely voluntary community, that is all > that can be done. They do not have alpha, beta etc, they have release > candidate and release. I suspect that those projects where there are > companies backing them and paid developers, these things are more > systematic. would suffice if that could be brought out in a generic way. by-and-large its similar - terms vary. > Anyway if you have some experiences in these, please share. > (Koha has paid developers too) today a popular Open Source Software would mean that it has to be packaged & made readily available as binary for installation atleast in two family of distros - debian & fedora. post development - building them to get the binaries for various architectures & taking them to repos/ maintaining there or under one's own repo can be given some priority. -- amachu ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Tue, 2012-06-05 at 15:08 +0530, ஆமாச்சு wrote: > > this very rarely works out. My motto is - if you do not have a > client, > > do not write software. > > i am saying the practises adopted by Ubuntu, Fedora, Koha, Django, > KDE, > GNOME, OpenERP etc., > > How they put forth a timeline for every release, call for features to > be > added, bugs to be fixed, deadlines for translations, then alpha, beta > then the final release. the only one I am familiar with is django - they fix a rough date for release, but release when it is ready. They have rough list of features for release, but those features get included only if someone gets them ready. Same with translations. As for bugs, those described as release blockers are fixed before release, if someone fixes others, they get included in the release. In a purely voluntary community, that is all that can be done. They do not have alpha, beta etc, they have release candidate and release. I suspect that those projects where there are companies backing them and paid developers, these things are more systematic. Anyway if you have some experiences in these, please share. (Koha has paid developers too) -- regards Kenneth Gonsalves ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On 06/05/2012 12:28 PM, kenneth gonsalves wrote: > this goes for open source also. Most successful open source applications > were originally developed for a client who paid for it and then made > open source - examples are django and koha. Known as the 'sell it, free > it' model. yes. there are cases like this. ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On 06/05/2012 12:28 PM, kenneth gonsalves wrote: > this very rarely works out. My motto is - if you do not have a client, > do not write software. i am saying the practises adopted by Ubuntu, Fedora, Koha, Django, KDE, GNOME, OpenERP etc., How they put forth a timeline for every release, call for features to be added, bugs to be fixed, deadlines for translations, then alpha, beta then the final release. Post release the approach they have for fixing bugs, how they release updates etc., This is something crucial to understand. ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Tue, 2012-06-05 at 11:16 +0530, ஆமாச்சு wrote: > On 06/05/2012 10:32 AM, kenneth gonsalves wrote: > > after some research, I find that this is the classic waterfall model > of > > software development, > > private software development goes this way - you develop something > for > someone. this goes for open source also. Most successful open source applications were originally developed for a client who paid for it and then made open source - examples are django and koha. Known as the 'sell it, free it' model. In fact someone once said that if you cannot sell it, no one will take it even if you give it free. > > When it comes to creations - you develop something & then reach out > selling subscriptions, then the development practices involved under > such scenarios, also need to get covered. this very rarely works out. My motto is - if you do not have a client, do not write software. -- regards Kenneth Gonsalves ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On 06/05/2012 10:32 AM, kenneth gonsalves wrote: > after some research, I find that this is the classic waterfall model of > software development, private software development goes this way - you develop something for someone. When it comes to creations - you develop something & then reach out selling subscriptions, then the development practices involved under such scenarios, also need to get covered. -- Amachu ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Fri, 2012-06-01 at 16:49 +0530, kenneth gonsalves wrote: > I have had > only 3 experiences in developing prop, and all ended up in my being > booted out fairly early in the process, so I am not sure if my > observations are accurate. The cycle as I see it is like this: > > 1. Sales meets the clients and promises them anything under the sun, > fix > a price and get an agreement and an advance. After that sales is out > of > the picture. > > 2. Design then meets the clients and draw up an elaborate set of specs > and get the client's approval. After that, design is out of the > picture. > > 3. The design is then sent to production. The job is parceled out to > several teams, each team working in isolation from the other teams. I > will not go into how these teams operate, but the general atmosphere > is > - if it works, it is fine and peer review and criticism of another's > code is seen as a deadly insult. Obviously a lot of the code is > duplicated as no team knows what the other teams are doing, and, no > one > will anyway admit that another person's solution is better than his. > Note that the teams do not have any contact with the clients. When the > teams finish their assignments, most of the members move on to other > projects leaving a skeleton team to cope with the next stage. > > 4. Now the integration team moves in. They are the elite and highly > paid > and their job is to somehow get everything to work together. They do a > lot of reverse engineering and 'adjustments' and finally pronounce > themselves satisfied. > > 5. Then testing takes over - all tests are with simulated data and > with > the help of the integrators the tests are pronounced done. > > 6. The product is then dumped on the hapless client and he is left to > the tender mercies of support. In the period of development, a lot of > his needs have changed and he needs many things he has not contracted > for. Also with real data, many bugs appear. Some clients decide to > live > with it - others go to another vendor, and the same process starts > again. The client very often spends more to get the whole thing > working > in some fashion or the other than on the original application. after some research, I find that this is the classic waterfall model of software development, and better firms try different approaches like extreme programming, scrum, agile etc. Has anyone had experience with firms in india that follow these methods? -- regards Kenneth Gonsalves ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Sat, 2012-06-02 at 20:46 +0530, Arun Khan wrote: > On Fri, Jun 1, 2012 at 4:49 PM, kenneth gonsalves > wrote: > > ... snip ... > > I will share my experience at a prop. software shop (Bell Labs). > > > 3. The design is then sent to production. The job is parceled out to > > several teams, each team working in isolation from the other teams. > I > > will not go into how these teams operate, but the general atmosphere > is > > - if it works, it is fine and peer review and criticism of another's > > code is seen as a deadly insult. > > Every developer had to write a high level design document (interfaces, > db, real time requirements etc.) which got broken into Design Units > (Code). The DU doc had pseudo code and/or flow charts showing how each > C function would work. > > Each document was reviewed by peers and senior members. The document > would not be accepted until major/severe bugs were resolved. Ditto > with DU - Code could not deviate from that mentioned in the DU docwent > through inspection and walk through by peers and module owners. > Again, code not be submitted for integration until all errors were > resolved. This does not mean that the entire system was bug free but > the philosophy was to catch as many bugs before they crept into the > system. I personally feel that too much design and specs strangle a project, but admittedly my experiences is in end user applications - not the kind of thing Bell labs does. Further, Bell labs is Bell labs. > > > Obviously a lot of the code is > > duplicated as no team knows what the other teams are doing, and, no > one > > will anyway admit that another person's solution is better than his. > > Note that the teams do not have any contact with the clients. When > the > > teams finish their assignments, most of the members move on to other > > projects leaving a skeleton team to cope with the next stage. > > Every developer had access to *all* the code in *all* the sub systems > - no code duplication. Peers suggested code improvements during the > inspection stage (I learnt a few tricks in C from peers this way). this is crucial - I would not call this proprietary development model though -- regards Kenneth Gonsalves ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Fri, Jun 1, 2012 at 4:49 PM, kenneth gonsalves wrote: ... snip ... I will share my experience at a prop. software shop (Bell Labs). > 3. The design is then sent to production. The job is parceled out to > several teams, each team working in isolation from the other teams. I > will not go into how these teams operate, but the general atmosphere is > - if it works, it is fine and peer review and criticism of another's > code is seen as a deadly insult. Every developer had to write a high level design document (interfaces, db, real time requirements etc.) which got broken into Design Units (Code). The DU doc had pseudo code and/or flow charts showing how each C function would work. Each document was reviewed by peers and senior members. The document would not be accepted until major/severe bugs were resolved. Ditto with DU - Code could not deviate from that mentioned in the DU docwent through inspection and walk through by peers and module owners. Again, code not be submitted for integration until all errors were resolved. This does not mean that the entire system was bug free but the philosophy was to catch as many bugs before they crept into the system. > Obviously a lot of the code is > duplicated as no team knows what the other teams are doing, and, no one > will anyway admit that another person's solution is better than his. > Note that the teams do not have any contact with the clients. When the > teams finish their assignments, most of the members move on to other > projects leaving a skeleton team to cope with the next stage. Every developer had access to *all* the code in *all* the sub systems - no code duplication. Peers suggested code improvements during the inspection stage (I learnt a few tricks in C from peers this way). Project management meetings were tough; managers would ask tough technical questions (they knew the product). Coming from this background, I was appalled at the practices in other companies that you have succinctly outlined. -- Arun Khan ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Tue, 2012-05-29 at 21:41 +0530, Balachandran Sivakumar wrote: > Hi Kenneth, > > On Tue, May 29, 2012 at 6:32 PM, kenneth gonsalves > wrote: > > has anyone have any idea as to what is meant by 'software development > > practices' and whether this term is applicable to open source software > > development? > > > Software development practices are applicable to any > software - irrespective of open source or not. The term, simply put, > means an organised and scientific way of creating software. To state a > few examples: use of a version control system, collecting and > documenting the requirements for which we are developing the software, > etc. > > In the open source world, development practices include having a > writing well-commented code, dev wiki, dev mailing list, a public bug > tracker, (at least) a basic How To for the users, a proper build > system, etc. Thanks > > (caveat: this post is based mainly on personal experience and put here to see how others in both the open source field and the proprietary field feel about this) thanks to all who responded. I now understand that the term is supposed to mean the development cycle for a software project. This, in my opinion, is radically different for foss and prop software. I have had only 3 experiences in developing prop, and all ended up in my being booted out fairly early in the process, so I am not sure if my observations are accurate. The cycle as I see it is like this: 1. Sales meets the clients and promises them anything under the sun, fix a price and get an agreement and an advance. After that sales is out of the picture. 2. Design then meets the clients and draw up an elaborate set of specs and get the client's approval. After that, design is out of the picture. 3. The design is then sent to production. The job is parceled out to several teams, each team working in isolation from the other teams. I will not go into how these teams operate, but the general atmosphere is - if it works, it is fine and peer review and criticism of another's code is seen as a deadly insult. Obviously a lot of the code is duplicated as no team knows what the other teams are doing, and, no one will anyway admit that another person's solution is better than his. Note that the teams do not have any contact with the clients. When the teams finish their assignments, most of the members move on to other projects leaving a skeleton team to cope with the next stage. 4. Now the integration team moves in. They are the elite and highly paid and their job is to somehow get everything to work together. They do a lot of reverse engineering and 'adjustments' and finally pronounce themselves satisfied. 5. Then testing takes over - all tests are with simulated data and with the help of the integrators the tests are pronounced done. 6. The product is then dumped on the hapless client and he is left to the tender mercies of support. In the period of development, a lot of his needs have changed and he needs many things he has not contracted for. Also with real data, many bugs appear. Some clients decide to live with it - others go to another vendor, and the same process starts again. The client very often spends more to get the whole thing working in some fashion or the other than on the original application. note that the tools used are irrelevant to the process. Of course people will say that these practices are only followed by lowlifes, and good software developers use a lot of open source tools and methods and are very scientific in their approach. So let us look at IBM. Produces great software, is ethical and a very sound supporter of open source. Some years back a wildly hilarious discussion went on in the django developers mailing list. The thread is here: http://groups.google.com/group/django-developers/browse_thread/thread/80f73f8bbf93c039/d598b3d4d67301a8?#d598b3d4d67301a8 To summarise the thread, IBM wanted to release Django drivers for their databases, so they asked the Django developers for the 'specs'. The reply: download django, make a copy of an existing driver, tweak it for your database, make sure it passes all the tests and you have a driver. IBM was horrified - we cannot download or even look at your code as our engineers will get tainted and we can no longer use them - so give us specs. The django team was not willing to waste their time on this. Eventually IBM released the drivers. I suppose they got some engineer to look at the code, write the specs and then they must have terminated him with extreme prejudice ;-) When pharaoh died, he was buried with all his wealth. The tomb was cleverly constructed with a lot of booby traps to prevent looters from getting in. Often the location was secret. And the architects, builders and slaves who built the tomb were killed and buried with him - all in the name of secrecy and security. Prop software has two constraints - one cannot reuse code (even code written by the concern for another client)
Re: [Ilugc] software development practices
Hello Animesh here, .I am working as PHP web developer in Quadruple Business Services.I would like to say irrespective of any technology s/w development practice is followed whether it is open source or not.S/w development practice is nothing but sdlc ie client requirement or gathering ,analysis,mockup for ui,programming,testing and maintainence.For this process team select s/w development method ie watercycle model,agile model or scrum depending upon project and project timeline. Thanks -- "It is not important to hold all the good cards in life.But it is important how well you play with the cards which you hold." Animesh Sheolikar ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Tue, 2012-05-29 at 15:20 +0200, Krishna wrote: > > has anyone have any idea as to what is meant by 'software > development > > practices' and whether this term is applicable to open source > software > > development? > > > > > Can you please elaborate more in detail, in what context are you > asking > this question?. I am supposed to write something on this topic. Searching the web is giving confusing results. So those of you who develop software may be in a position to elaborate on the conventional meaning of this term. -- regards Kenneth Gonsalves ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
Hi Kenneth, On Tue, May 29, 2012 at 6:32 PM, kenneth gonsalves wrote: > has anyone have any idea as to what is meant by 'software development > practices' and whether this term is applicable to open source software > development? Software development practices are applicable to any software - irrespective of open source or not. The term, simply put, means an organised and scientific way of creating software. To state a few examples: use of a version control system, collecting and documenting the requirements for which we are developing the software, etc. In the open source world, development practices include having a writing well-commented code, dev wiki, dev mailing list, a public bug tracker, (at least) a basic How To for the users, a proper build system, etc. Thanks -- Thank you Balachandran Sivakumar Arise Awake and stop not till the goal is reached. - Swami Vivekananda Mail: benignb...@gmail.com Blog: http://benignbala.wordpress.com/ ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Tue, May 29, 2012 at 6:32 PM, kenneth gonsalves wrote: > hi, > > has anyone have any idea as to what is meant by 'software development > practices' and whether this term is applicable to open source software > development? > > I guess it refers to the workflow followed from the time you decide to work on a software till it is sent to production. It covers requirements gathering, UI design, s/w architecture, testing, version control, bug fixing etc. So every s/w developed went through a development practice - even if it was not consciously done. Clients might feel comfortable if a vendor has a documented s/w dev practice - on the assumption that it is actually followed :-) regds, mano ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] software development practices
On Tue, May 29, 2012 at 3:02 PM, kenneth gonsalves wrote: > hi, > > has anyone have any idea as to what is meant by 'software development > practices' and whether this term is applicable to open source software > development? > > Can you please elaborate more in detail, in what context are you asking this question?. -Krishna. ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
[Ilugc] software development practices
hi, has anyone have any idea as to what is meant by 'software development practices' and whether this term is applicable to open source software development? -- regards Kenneth Gonsalves ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
