SlideShare a Scribd company logo
1 of 10
Download to read offline
Ad hoc 2.0 – The New Generation

                                            Nuno Brito
                           CMU/UC Master of Software Engineering 2009/2010
                                  Managing Software Development
                                     nbrito@andrew.cmu.edu


                       Abstract                              long time as essential to improve the odds of success
                                                             for a professional project in the software industry [4].
Ad hoc software development is the construction of
software solutions through methods and techniques            However, with the advent of massive access to the
that are most often developed from scratch during            Internet came the emancipation of end-users, providing
project development. Although a reputation of limited        the conditions that allowed them to evolve from a
flexibility and scalability haunts this methodology, it is   passive state onto active positions inside the project as
nevertheless a powerful technique to build and deploy        beta-testers or even becoming active developers that
applications or prototypes within a short period of          help to carry forward the progress and lead the project
time.                                                        to success. The power of this type of cooperative
Ad hoc will not scale in the traditional format that is      development is well described by Eric S. Raymond in
known to software engineers, but web 2.0 platforms           “The Cathedral and the Bazaar” [5].
such as forums, blogs and social networks combined
with accessible development frameworks are now               The Internet thrives at a web 2.0 era as a global
reviving the ad hoc philosophy as a valid approach to        platform that is reachable to a far wider stream of the
developers where this scaling/complexity limitation is       population when compared to web 1.0. People from
not an obstacle anymore. Even thought it is not a            any gender, age or technical background can
magic bullet that can solve the issues that arise from       effectively communicate, work, produce and share
avoiding a more complete and formal methodology,             knowledge on a global scale with a relative ease. There
this is nevertheless a growing and attractive trend          is an emergent new generation of software projects that
amongst many small sized software projects to produce        follow the old ad hoc approach principles but are no
software capable of rivaling side by side commercial         longer tied to a restricted group of people involved into
applications from professional developments, resulting       development with a high level of knowledge on
in what we define as Ad Hoc 2.0 – The new generation.        professional programming activities [2].

                                                             On this paper, we will begin by focusing on the way
                                                             how ad hoc is currently perceived from a professional
1. Introduction                                              perspective and then perform a more in depth analysis
                                                             to attempt understanding the advantages and
Where does the term Ad hoc come from?                        disadvantages that arise from this methodology when
Ad hoc is a Latin phrase which means "for this               contextualized inside a software engineering plan.
[purpose]". It is a common practice to use this term for     Later, we approach the concept of Ad hoc 2.0 from a
describing specific solutions applied to a given task or     high level perspective that explores the reasons why
problem which cannot be generalized or adapted to            it’s use is made possible and attempt to identify
other purposes.                                              common life cycles that projects following this
In the context of software development, an ad hoc            methodology might eventually follow. We will then
methodology is often associated to a short life cycle        focus on real examples of projects built and maintained
span, or even to the lack of architecture that addresses     with some success while employing this methodology
scalability and completeness since the early project         to some extent and analyze some of the characteristics
inception. These are characteristics recognized since a      that can either lead to success or failure the future of a
                                                             project in terms of longevity and large scale software
                                                             development.
since its inception, but a development process is also
Before we start dwelling onto the definitions between          driven from the developer’s talent and effort which
ad hoc in the traditional format and the new format that       tends to avoid formalized processes that present
is the topic of this paper, it should be noted that there      restrictions to creativity and innovation [13]. When
are some ambiguities regarding the terms: “life cycle”,        integrated at an open and global market environment
“methodology” and “process” related to the                     where innovation and competition are more often than
development of projects.                                       not the aggressive points that help to establish success
                                                               [7], can we continue to assume as a correct to regard ad
The author will adopt a consistent and contextualized          hoc approaches in such negative manner to the point of
definition of each term throughout the paper in order to       software engineers completely discard them as an
ease its overall meaning at each paragraph. To help            efficient solution for professional software industry
clarify what each term is usually referred to, some            products?
explanation about each term is due: “Process” refers
to the tasks that are executed inside each phase of            The criticism mentioned on CMMI about the
development. “Methodology” refers to the set of                precarious style of developing software is certainly true
techniques and methods that are employed on these              in most of it’s extent, but it is also true that software
processes. “Life cycle” is referring to all phases of the      developers still apply ad hoc in their everyday work as
project since it’s early inception until it’s final state of   an intuitive and efficient way to manage the resources
release of the product to the customer including               available to them. This is an approach that allows a
posterior phases (if any) as help desk support and             project in a real world of software competition where
maintenance for example.                                       high levels of creativity under a tight budget of time
                                                               and resources become so critical as necessary to
                                                               survive.
2. Traditional Ad Hoc development
                                                               The most interesting force that drives ad hoc as a
                                                               compelling approach is the (in)famous preference for a
2. 1. Concept                                                  lack of formal processes since the early inception of
                                                               the project. There is a common misconception that ad
Software engineering often tends to consider Ad hoc            hoc followers do not follow any formalized process,
with a negative impression when it comes to choose a           the truth lies in the fact that an ad hoc project will
life cycle solution against a formal approach.                 simply be developed without a specific process
                                                               methodology followed from a strict and formal manner
   SEI (Software Engineering Institute), characterizes         since the beginning. Eventually, some formal processes
ad Hoc in “CMMI for development” [10] as a                     do tend to surface after they are tested and considered
methodology belonging to the lowest possible level:            as fit to the custom needs of the project in question but
“At maturity level 1, processes are usually ad hoc and         this misconception might lead assumptions that
chaotic. The organization usually does not provide a           characterize the overall development as “hackish” or
stable environment to support the processes. Success in        even as “chaotic” when viewed from an external
these organizations depends on the competence and              perspective that is not aware of how these formal
heroics of the people in the organization and not on the       processes are unique to the project in question even if
use of proven processes. In spite of this chaos, maturity      they don’t follow a standardized approach.
level 1 organizations often produce products and
services that work; however, they frequently exceed            Using nothing more than know-how from the team of
their budgets and do not meet their schedules. Maturity        developers mixed with experience acquired during the
level 1 organizations are characterized by a tendency          project’s life cycle, an ad hoc project can ensure in
to over commit, abandonment of processes in a time of          most cases that whatever processes are adopted along
crisis, and an inability to repeat their successes.”           the development cycle, they will eventually be
                                                               modified enough to the point of sufficing the needs of
Formal methodologies will often attempt to follow a            the project to some extent. The level of efficiency
predefined set of stages intended that provide a certain       resulting from these ongoing ad hoc processes is
quality level and management control, in some cases,           perhaps questionable as it will depend directly from the
even allow certification of their software practices           proficiency and talent of the team elements or even
from a third party entity. These are recognizable              derive from user feedback that helps them to be
characteristics for a well engineered product that is          elaborated. This is an approach that carries advantages
aimed to reach a higher level of CMMI maturity [10]
and disadvantages that will be explored over the next         on ad hoc as an approach to allow exploring
section.                                                      competitive solutions on the market that allows to
                                                              quick releases to public and outperform competitors.
2.2. Advantages and Pitfalls                                  We can identify and detail some of the reasons for this
                                                              negative fame:
Ad hoc still holds several advantages as a development            • Poor practice of requirements’ elicitation - no
approach since it is well adjusted for projects of                     predefined set of procedures to properly
relatively small to medium dimension that can be made                  conduct a requirements elicitation process that
available when time and expected results don't justify                 allows understanding the scope of a given
the cost of instantiating a formal process.                            problem. Raising the risk that a given project
                                                                       can drive a team to waste efforts on solving
For example, ad hoc approaches are very well applied                   superficial symptoms instead of actually
to cases where a given project requires a proof of                     solving the reason that causes the problem or
concept before engaging onto a full scale development                  even mixing requirements with a possible
following a formal approach, or perhaps applied to                     solution.
projects that are meant for internal use, where
customer, developers and end-users all belong to the              •    Quality assurance is not measured nor
same company and a formal process is considered to                     conducted efficiently - without using an
add unnecessary overhead to deliver the product.                       efficient strategy for early defect detection or
                                                                       procedures to continuously assess overall
Ad hoc can sustain a high level of motivation and                      quality through methods such as Fagan
interest from a team since it allows developing a                      inspections [12], a high density of defects will
project in a light-weight manner that is intended for                  eventually be discovered after releasing the
release within a short term of time, this is a good                    initial product version to the customer.
manner to promote innovation and creativity to take
place without too many barriers to development,                   •    Lack of scalability or generality, ad hoc
however, allowing a project to be developed without                    projects focus their target to a specific
formal methodologies and depending solely on the                       audience     with    specific    needs.    This
experience from developers is also a risk that raises the              characteristic will constraint since the initial
odds of impact from several disadvantages that need to                 days of development the range of evolution
be considered before engaging into this sort of practice.              that can be expected in terms of scope, size
                                                                       and complexity when planning to grow in all
What specific reasons keep companies away from                         these dimensions. We'll explore this particular
adopting Ad Hoc?                                                       characteristic over the next section of this
                                                                       paper.
Ad hoc inherited a very negative image since the 90’s.
This is the worse factor that still prevents at present its   2.3. Scalability of ad hoc projects
official adoption by professional software developers.
It will also remain as the cause to which people will         Scalability is an often desired characteristic on
point their finger when looking for a reason to blame         commercial projects that seek a growing number of
for a never-ending appearance of problems that arise          end-users as it might bring a proportional growth in
when the inherent limitations to this approach are not        revenue. But if the base of end-users grows
properly understood. This approach suffers from the           continuously over time, the project will also tend to
same type of issue often associated to companies who          inevitably increase in size and complexity. As result,
avoid XP or generic Agile methodologies after passing         features will be added, exposed defects will require
through negative experiences due to their initial lack of     correction, support for end users and legacy
experience in the agile approach to begin with. This          maintenance for older versions will need to be
same factor inducts a catch-22 type of problem where a        provided in a scale that will surely continue increasing.
company that publicly admits to use ad hoc on their
projects will suffer to pass onto the outside world an        Scalability will therefore impact the development
image where quality and efficiency are not perceived          resources that were originally allocated to a given
as reliable, thus causing impact on the reputation, but       ongoing project [1]. Ad hoc is rarely prepared to the
underneath the hood, the same company can still rely          endurance of time and increase of user base over long
terms of time. A project based on ad hoc architecture
will demonstrate it's inadequacy to survive as               Open source projects are most often characterized as a
complexity increases, often requiring a complete             geographically disperse group of volunteer developers
rebuild from the ground up to match the expected level       that enlist themselves to aid at tasks suited for their
of usage and efficiency - perhaps even employing a           talent which eventually keep a project moving forward
formal process to achieve the intended results for the       on a good level of progress if it retains the attention of
future and no longer be labeled as ad hoc.                   an audience. The popularity, influence and success of a
                                                             given open source project can therefore be directly
These are the most common reasons why companies              measured in most cases by the number of users and
choose a formal development process from the start.          volunteers that work to ensure it's long term longevity.
Characteristics such as scalability and maintainability
over the long term are planned right from the early          The approach for developing these projects when they
project inception and the gain from a quick start and        are small sized can be loose and sporadic. But when
delivery as provided by ad hoc will only come with           these projects start growing across several dimensions
higher costs to solve as the project itself grows bigger.    such as complexity and user base - then a natural
Even thought the bad reputation assigned to ad hoc can       tendency to adopt a strict and formal set of
sometimes be considered as exaggerated since people          methodologies that allow a team to keep the overall
tend to pick examples where it is certainly not an           processes of development under control will eventually
appropriate approach, the truth is that its limitations in   begin to surface.
the traditional format are both a blessing and course
that will limit its usage to developers with significant     So, we can conclude that regardless of the nature from
experience in the software industry to take advantage        a given software product being open source or closed
of most benefits it has to offer without suffering most      source, if the dimension of this project belongs to mid
of the recognized pitfalls.                                  or large size and complexity then it will eventually
                                                             need to increase the control over the processes for
However, a new generation of ad hoc is surfacing that        developing software in the long term if the overall
does not require an extensive experience on software         project’s goal is to remain active and popular.
development nor is limited to the same boundaries of
the traditional ad hoc format as before. We will now         Traditional Ad hoc usage can be found necessary to
introduce this new concept over the next section.            kickstart a project that follows either the open or closed
                                                             source type of methodology, we also mentioned
                                                             previously that exists a natural evolution of a project to
3. Ad hoc 2.0 – The New Generation                           somehow expect a progressive formalization of the ad
                                                             hoc processes to also occur if enough time is given.

It is a fact that the Internet plays an important role as    Or, in more extreme situations, the developers from an
communication platform for people that wouldn't              initially ad hoc project can decide to redesign it from
otherwise group together.                                    scratch, using then the formal methods that are more
This access to the Internet world influenced the             appropriate to generate a new architecture based on
software development paradigm as reported by Eric S.         lessons gathered from past experience on the
Raymond in “The Cathedral and the Bazaar” [5].               development effort. Failing to evolve onto this
However, Eric’s study is mainly focused on the               formalized phase of development might eventually
contrasting differences from closed source projects          lead a project to stagnation or increase the risk of
compared to open source movements and leaves out             becoming overrun by other competing projects.
some of the interesting management techniques that
allowed ad hoc processes to efficiently manage               We can therefore infer that a project cannot use
resources in large scale software development projects.      traditional ad hoc methodologies as a sustainable
                                                             solution for a long term of time and this fact remained
Both open and close source movements share concerns          as a solid truth since a long time ago. But when ad hoc
that are similar to some extent about the question of        meets the Internet of masses, an exciting new twist on
human managing, quality control and customer                 the fate of ad hoc projects allows breaking this rule.
satisfaction even thought they are following different
approaches regarding the way how software should be          The audience of users interested in joining efforts to
developed.                                                   help a given project for absolutely no cost allows
                                                             people to organize themselves and develop a project by
voluntarily assuming the responsibilities of specific       developers can effectively rival against products
roles inside these ad hoc processes. Groups of people       developed from commercial companies or provide
will form effective development teams that can per          solutions that wouldn’t otherwise be explored by
times outperform professional developers. This can be       commercial groups.
due to the high level of motivation and feedback from
multiple perspectives provided by direct contact            Ad hoc 2.0 projects have no roadmaps defined for each
between end-users and product developers. People            development phase and can often be defined as an
involved in ad hoc 2.0 projects will usually share the      ongoing development work whose progress is based on
same domain knowledge in a similar manner to what           volunteers and continuous feedback from users.
currently occurs with open source movements.
                                                            3.1. Typical life-cycle of an Ad Hoc 2.0 project
There are situations were this type of ad hoc is the
ideal situation for decentralized development without       What can be expected from Ad Hoc 2.0?
requiring a high level of control or management. When
efforts are based on cooperative work from volunteers       This is a flexible approach. There is no structure that
that are not confined to a strict and formal organization   can accurately describe a similar pattern across projects
as noted on many open source movements of bigger            of this particular kind, nevertheless, it is possible to
dimension, development will become intuitive and            distinguish a few phases that are likely to occur during
dynamic, adapting more easily to the newer trends of        the project lifetime.
technology without added costs. This type of specific
volunteer movement can be found across many other           The ideal team development condition to allow
projects of small dimension whose code is not               forming an Ad hoc 2.0 approach are situations where
necessarily released to the public but where people still   only a single developer or a small number of
offer their time and talent to help in tasks such as        developers between 2 up to 5 elements are included.
language translation, beta testing, help desk support or    There may exist several team elements assigned with
whichever tasks required.                                   secondary roles such as beta testers and such, but the
                                                            primary team elements should always be responsible
There is an ongoing trend where the exclusive use of        for the most important decisions regarding the project
web 2.0 technologies such as bulletin boards, blogs or      progress while sharing the role of end-users on the
any other social networks will allow people across the      same project.
globe to communicate and share knowledge between
them. These are the ideal locations where an ad hoc         The lifecycle for an Ad hoc 2.0 project will typically
project can progress and reach popularity with the          follow 5 distinct phases of development.
increase of users and complexity while withstanding
the test of time without ever requiring the move onto           1.   Idea – The concept for a given project is
more formalized practices as seen in the traditional ad              proposed by a developer or small group of
hoc format.                                                          developers to solve a given problem or
                                                                     challenge. A brainstorm session between
There is no extensive roadmap, no architecture plan is               some of the stakeholders occurs and attempts
detailed, no monitoring of milestones nor extensive                  to identify possible competitors, alternatives
quality control is conducted, and yet, these are projects            and involved complexity to carry forward the
that still manage to provide a product or service that               project onto a feasible success.
reaches success and even outperform professional
developments under some situations. This is what we             2.   Implementation – The project begins
identify as “Ad hoc 2.0 – the new generation”.                       implementation shortly after the idea is
                                                                     accepted as achievable. The project will likely
It's a concept for developing software where some of                 be coded using a software framework that is
the common disadvantages identified from traditional                 familiar to the developers.
ad hoc are eventually solved or not even considered
relevant to some extent. There is an important human            3.   Initial version – A first version is made
value that is raised from this mass number of users that             available to the public as proof of concept that
allows these projects to keep moving forward                         the innovating idea for the project can be
regardless of their complexity. These projects can be                achieved. Usually released to a small group of
based solely on the help and talent from volunteers. It’s            people that are close to the development circle
the type of methodology where small groups of                        in order to gather feedback.
development of the project;
    4.   Revision / Beta versions – Incremental beta              7.  Easy to manage– doesn't require team
         releases and versions considered as stable are               elements to posses a specific formal
         published to address bugs or requested                       education on software development and
         features. Very active participation of end-                  management, a small team is capable of
         users in this stage.                                         develop a good product using common
                                                                      good sense to solve most situations;
    5.   Stagnation – A project eventually reaches a              8. Lightweight – can be instantiated in a
         state of inactivity and either doesn’t fulfill               short period of time and keep the
         requests from end-users or there is not enough               motivation of the involved developers at
         interest from the community where it is                      a very high level of engagement as the
         discussed to provide additional feedback.                    project results are visible very quickly;
         Stagnation occurs since the project                      9. High number of versions released to the
         development is neither announced as                          public that address new features or
         terminated nor the responsible developers will               defects fixes;
         provide insightful news regarding the project            10. Development driven by user feedback,
         progress in the future.                                      progress occurs according to motivation
                                                                      of authors and user base requests. If a
3.2. Advantages and disadvantages                                     project is popular then it might act as a
                                                                      good motivator for the author to proceed
Ad hoc 2.0 under this new context remains truthful to                 with further development;
it's origins – avoid formal processes from the
beginning, change and adapt as necessary in order to      And also some disadvantages:
survive. To avoid an extensive list of characteristics,
we narrowed the scope down to 10 advantages and 10                1.   It's not prepared to scale or handle
disadvantages that seem relevant to expose on this                     complexity by default, the effort required
particular development methodology.                                    to adapt onto a bigger user base or code
                                                                       complexity might be overwhelming for a
Advantages that are commonly found:                                    small development team;
                                                                  2.   No formalized quality assessment as
         1.   Good for volunteer work as people can                    there are no repeatable processes to
              join at any given time as beta testers or                ensure that the project development
              even developers in some situations;                      doesn't cause conflicts with previous
         2.   Well adjusted to small sized projects as                 development effort [12];
              the level of complexity can still be                3.   No metrics defined to evaluate project
              completely manageable by a single                        status makes the task of tracking progress
              developers or small team of developers;                  more difficult to understand by everyone
         3.   Allows to build strong relationships with                involved in the project;
              users since they also become an active              4.   Risks are often not clearly explored and
              part of the development process as beta                  analyzed before proceeding with project
              testers or other roles to which they                     development, this might force developers
              volunteer and help the project effort                    to deal with unexpected risks that could
              move forward;                                            have been avoided from the start;
         4.   Affordable – requires few resources since           5.   No clear milestones with well defined
              inception and the development team can                   goals as the project is governed by the
              in most of the cases work on the project                 specific needs at any given time.
              during his free time as a hobby;                         Defining milestones is a very difficult
         5.   Localized – solves an immediate need of                  task unless there is a clear goal to achieve
              a specific audience instead of requiring                 from the beginning;
              support for a much wider array of                   6.   Requirements' elicitation is often
              possible users;                                          incomplete as developers tend to opt by
         6.   Flexible – adjusts well to new                           delivering a quick fix or patch to solve
              requirements that may appear during                      the symptoms of a problem without
              development or to new situations that                    focusing on the reason that is causing it in
              may cause a significant drift on the                     the first place.
7.  No schedule is usually defined in most        level of built-in functionality that wouldn’t otherwise
             cases as the project progress will depend     allow these small sized teams to quickly produce
             on the effort and motivation from the         applications based on already built user interfaces and
             developers, which might lead to               many other components that are stable and allow them
             prolonged states of stagnation;               to focus efforts on innovation.
         8. High rate of bugs since new versions are
             often released to public without extensive    In order for a given project to achieve a competitive
             debugging care and often rely on user         level and maintain this position, the software processes
             feedback to detect defects and prioritize     that are employed should also be based on flexibility
             their fix.                                    and extensibility rather than high quality as mentioned
         9. Defects are not reported with enough           by Nogueira in “Surfing the edge of chaos”[11]. The
             details because users are not properly        goal is to maintain a balance between innovation and
             trained for this task, often leading to       public interest. Assuming that an ad hoc methodology
             ambiguous or incomplete reports about a       allows a project to reach the top of it's initial
             defect that needs to be corrected.            expectations and is well adjusted to keep a large
         10. Too many different versions are difficult     percentage of users happy with the product for a long
             to use and might even paralyze any effort     period of time, then there is an important question that
             to bring simplicity into a version system     needs to be asked: where can software engineering be
             that attempts to distinguish between          found under this new paradigm?
             stable and unstable versions of the
             product.                                      We devote the next section to clarify this question and
                                                           the implications of processes when viewed from a
Previously, Ad hoc methods would be found applied          software engineering perspective.
mostly to software built with the focus on a specific
target audience, the “users by the dozens” [4]. Access     3.3. Surviving to scalability and long-term
to the Internet allowed this specific target audience to   development
become amplified from mere dozens to hundreds or
even thousands of users on daily basis.                    The most desired characteristic in Ad hoc 2.0 projects
                                                           is a successful transition to a higher scale of work and
This difference in the scale of masses places Ad hoc in    complexity that allows supporting a wide number of
a privileged position as most of the costs from            users and developers while increasing the overall
development and research can be reduced to a few           quality of services that are made available by the
single developers with talent. Success is often            project. Failing to evolve into a more adapted
measured by the amount of people who follow their          architecture for the project will eventually lead the
progresses and this is probably the way how software       overall development into a situation where the project
development can achieve its most emphatic form: a          will no longer be able to keep up with other competing
state of coding where the gap between developer and        projects.
end-users of the project is reduced to a bare minimum.
                                                           Software Engineering should be employed to explore
This flexibility to release a product often allows         more efficient engineering methodologies that are
publishing several minor version updates as prototypes     capable of producing processes adapted to a certain
that help developers get a better notion of the ideal      type of project and this same engineering practice now
product that answers the ever changing expectations        becomes necessary to ensure that this trend of software
from end-users. This type of approach often requires an    development can learn how to safely evolve onto a
uncertain number of releases and it’s very difficult to    more balanced level of development progress.
perform estimations or assessing the overall project
status but these are also factors that assume a smaller    A transition from an ad hoc approach onto a formalized
or less critical relevance in this context.                life cycle where processes, architecture and vision for
                                                           the project are already defined in advance is not an
The recent software development frameworks are also        easy task [14]. In order to understand how this
responsible in part for the existence of this new          approach should be executed, it is necessary to look on
generation of developers. Powerful frameworks are in       real examples from projects that somehow pioneered
most cases offered at no cost for developers (Eclipse,     the path for this thriving Ad hoc 2.0 philosophy,
Visual Studio) as the companies who develop them           strongly focused on the power of community work and
have also interest in their mass adoption, and provide a
attempt to understand some of the possible outcomes         depends on a single developer, Dino Nuhagic, which
for the future, even risking to never actually move onto    released the initial version in April 2004. This product
a state where formalized processes can be safely            was an immediate success ever since the initial release.
implemented with success.                                   Thought buggy, it would still allow users to save a
                                                            considerable amount of time that was previously
                                                            required to customize a given Microsoft Windows
4. Case Studies                                             installation source.

                                                               The project's development space for discussion was
One of the most seductive advantages of Ad Hoc              provided by MSFN (http://msfn.org) – a forum
development is the freedom to create and quickly            dedicated to the discussion of windows based
releases to the public a working version of the project     technology that was already popular at the time of
that ensures enough innovation and chaos will provide       nLite's presentation to public. At that time, this forum
encouragement for volunteers to help and motivate the       counted with an average of 342 visitors at each 30
developers into further progress.                           minutes. Using this site as base for discussing and
                                                            presenting incremental versions of the product, nLite
People developing a software product on their free          grew onto a user base of thousands over the initial 12
time and publishing it on the Internet will instinctively   months, reaching a state of recognized quality when it
be adopting an Ad hoc 2.0 lifestyle without necessarily     began being referenced by Microsoft in the official
becoming aware of their selection and inherent              knowledge base support channels.
consequences in most cases. It is important to promote
the investigation and elaboration of studies that allow     Remaining as a one-man-project, nLite evolved onto
to capture and understand some of the magic behind          vLite as the Microsoft Windows Vista Operative
this seemingly chaotic group of processes that seems        System was launched. When the family of software
nevertheless be working because of the human factor,        products developed by this author began increasing in
exactly as described previously by the CMMI.                terms of overall complexity aggravated by a significant
                                                            amount of new features added to each recent version,
Therefore, ad hoc is a human instinct approach, a           these factors began to toll a visible weight on the
specialized management technique that is applied            development effort. The author decided to cease
whenever processes seem to add excessive overhead,          development and declared product freeze in early 2008
are unknown to developers or fail to meet a given           at the peak of its popularity. Support to the products is
efficiency criteria – as mentioned before, even newer       still provided on volunteer basis at the forums but it is
software products can be released using this particular     grows increasingly outdated as the products do not
lifecycle as method to bootstrap them and evaluate          keep up with the newer released Microsoft Windows 7
their prospective popularity before engaging into a         and allows other competitors to compete for filling the
more formal development style.                              void left by a possible 7lite in the future.

As examples to showcase this style of development,          What happened?
three competing software products designed for the
Microsoft Windows platform were chosen. They all            Too many arguments can be formulated regarding the
started as products created by stand alone developers       reasons why the project came to halt. The author
that later evolved to large scale software systems due      himself claimed the need for free time to engage in a
to their expansion by components originated from third      professional software development activity. A project
party developers without direct relation to the             with increasing complexity and user requests was
development team in some cases.                             simply too much for a single person to support or one
                                                            can also consider that at some given point after so
4.1 nLite                                                   many years, the author lost its initial motivation to
                                                            pursue development of this project.
   nLite is a software product that allows users to
customize or remove specific components from a given        What we can infer is that in many aspects, this is still a
Microsoft Windows XP/2003 install CD or Microsoft           successful project today, but the fact that it remained as
Windows Vista install DVD. It will also allow to            a one-man-project was eventually a weak point that
integrate updates, automate the installation process and    allowed development freeze to occur.
integrate third party programs [6]. Its development
4.2 Bart's PE Builder                                      provided on the public forum by volunteers but the
                                                           exposed defects and user requested features that remain
    BartPE (Bart's Preinstalled Environment) is a          unanswered are a serious issue that undermines the
lightweight variant of Microsoft Windows XP or             attractiveness for users that now tend to adopt recent
Windows Server Operative System which can be run           Microsoft O.S. such as Microsoft Windows Vista and
from a CD or USB drive [8]. It was developed by Bart       Microsoft Windows 7.
Lagerweij. The exact date of release for the first
version is not simple to track but it was initially        4.3 WinBuilder
published in the early months of 2003 [9]. The product
was quickly marked with controversy at the time of         WinBuilder began as a community spin-off from the
launch. Microsoft was holding the monopoly for a           911cd.net forums into a brand new forum called Boot
solution targeted to Windows system administrators,        Land (http://boot-land.net) in mid 2005 [3] by a small
the new Operative System platform designated as            group of active users. This software project proposed
Windows PE – which was only available as a                 to solve some of the issues and feature requests that
commercially product to some organizations. BartPE         were not addressed by Bart's PE Builder at the time.
on the other hand, was offered completely for free and     The main goal of WinBuilder is similar to BartPE
allowed similar results without requiring a specific       regarding the flexible customization of Windows PE
license from MS.                                           boot disks with emphasis in allowing that users can
                                                           modify and improve the project, building components
This free solution to the commercial Windows PE            from top to bottom according to a given need.
(WinPE) from Microsoft allowed to gather a significant
number of end users, especially after Microsoft have       This flexibility allows building extremely tailored boot
no legal basis to contest the legal existence of BartPE,   disks projects. With the appearance of subsequent
which attracted considerable attention by the media.       Microsoft Windows platforms, WinBuilder became a
This alternative to WinPE was only deemed as legal by      software framework for popular projects such as
Microsoft as long as it would respect the Windows          LiveXP, VistaPE and Win7PE.
XP/2003 End User License Agreement (EULA).
                                                           Flexibility in excess also originated negative
In subsequent years, the product passed through 3          characteristics. Since each WinBuilder project is free
major versions and enjoyed extensive popularity. The       to define their own rules and organization, this ad hoc
third and latest version of this product was released in   approach causes a considerable lack of stable working
February 2006 [8].                                         structures for developers to share code and knowledge
                                                           across projects. Yet, development remains extremely
BartPE counted with support from the 911 CD Builder        active, based on volunteers that keep improving and
forum (http://911cd.net/forums), a forum that was well     providing updated versions of this software product
known at the time for hosting other freeware developed     and respective projects associated with it.
projects related to the customization of boot disks
based on MS Windows PE and MS DOS.                         Why is this working?

The success of BartPE eventually eclipsed popularity       Decentralized development is clearly present at the
of all other projects hosted at the same forum across      heart of this project. Each developer or team of
the years that passed and become the official meeting      developers doesn't depend exclusively on other
point for BartPE users around the world.                   developers and if the development of a given project
                                                           enters a freeze state – other volunteers can launch
Unlike nLite, there was no successor of BartPE to the      updated or even spin-off versions that eventually
Windows Vista platform and this gap was filled with a      provide a good degree of flexibility and progress that
competitor project called VistaPE from Sergey              outlives the initial author through other people that
Gurinovich in early 2007.                                  assume these positions in the development process.

What happened?                                             However, development processes have not yet been
                                                           formalized nor seems to exist any plan to formalize
The author stopped appearing on the public forums          them. Even thought activity remains very visible across
where his project was discussed and avoids replying        the several components of the project, new challenges
email messages regarding BartPE, leaving the project       are typically solved using an Ad hoc approach.
onto a development freeze state. Support is still
6. Conclusion                                               7. Acknowledgements
                                                            This paper would have not been possible without the
What can we learn from these examples?
                                                            support, feedback and help from those across the
                                                            Internet that embody this ad hoc 2.0 philosophy on
All three projects shared the same concept of ad hoc
                                                            daily basis without expecting more than a genuine
and unplanned development. Supported by Internet
                                                            “thank you” for their help to others. I’m grateful to
websites frequented by masses of users from a specific
                                                            have had the chance to meet some of these wise
target audience, these projects enjoyed a suited
                                                            internauts over the years and even observe from the
platform that helped gather new users and extend the
                                                            first row how these developments can truly succeed to
longevity of both the website as the project itself.
                                                            survive the test of time, scale and complexity. Would
                                                            like to thank in particular to Jacopo Lazzari (Italy),
This model of development is made possible even with
                                                            Peter Schlang (Germany), TheHive (USA), Cemal
scarce financial resources. Developers can code these
                                                            Tolga Talas (Turkiye) and David Kummerow
products as a hobby during their free time or secondary
                                                            (Australia) for their inspiring contribution for this
activity. Even thought the inception of a project first
                                                            paper.
occurs with the intent to solve a given challenge, these
products can remain actively used for years to come as
valuable working tools for thousands of users around
the globe in years to follow.                               8. References

As seen on the Windows PE case, Microsoft provided          1. Dean F. Sutherland, “A Tale of Three Processes”:
a commercial product to solve a particular market need      Reflection on Software Development Process Change
but was eventually driven to rethink their business         at Tartan.
model as the freely available alternatives succeeded in     2. Paul S. Adler, Beyond “Hacker Idiocy”: The
gaining the market attention and momentum. Later            Socialization Of Software Development.
versions of Windows PE (since 2.x and above) are now        3. Nuno Brito, “WinBuilder”: Case study, 2009.
made available for free for Microsoft Windows system        4. Clay Shirky, “Clay Shirky's Writings about the
administrators.                                             Internet”, March 2004.
                                                            5. Eric Steven Raymond, “The Cathedral and the
This sort of community-based development is also            Bazaar”, version 3.0, August 2002.
present in open source movements but on the types of        6. Wikipedia
cases in particular of software developments where the      “http://en.wikipedia.org/wiki/NLite_and_vLite”, as
source code is rarely made available to others, the         seen on 21st of November 2009.
project progress becomes extremely dependent from           7. Paine, Lynn Sharp & Royo, Jose. “Cimetrics
the motivation of the original author unless some           Technology” (A1)(9-399-108). Harvard Business
balance can be reached to overcome this dependency.         Online (2, February 1999), Paine 99
                                                            8. Wikipedia “http://en.wikipedia.org/wiki/BartPE”, as
Software Engineering could have helped the first two        seen on 21st of November 2009.
projects presented on this case to survive the test of      9. Bart Lagerweij,
time and continue to extend their popularity. Care          “http://www.911cd.net/forums//index.php?showtopic=
about the scalability of the project to newer Windows       837”, as seen on the 21st of November 2009.
platforms or quality assessment techniques might have       10. CMU / SEI - “CMMI for Development” 2006.
helped to simplify the overall software architecture if     11. Nogueira, et al. “Surfing the Edge of Chaos”:
they had been considered since the beginning of             Applications to Software Engineering, Naval
development but this was no the case unfortunately.         Postgraduate School.
                                                            12. Michael Fagan, “A history of software
A single person using Ad hoc to develop a software          inspections”: contributions to software engineering,
product with the proper basis in software engineering       Springer-Verlag New York, Inc., New York, NY, 2002
processes, awareness of this community power                13. Tom DeMarco & Timothy Lister, “Peopleware”:
provided by web 2.0 technologies, the right amount of       Productive projects and teams, Dorset Publishing
motivation that establishes empathy with a target           14. Brooks, "No Silver Bullet”: Essence and Accidents
audience, has all the right ingredients to achieve a very   of Software Engineering, Computer, 10-19, Apr. 1987
satisfactory level of success for the future.

More Related Content

What's hot

Why is dev ops essential for fintech development
Why is dev ops essential for fintech developmentWhy is dev ops essential for fintech development
Why is dev ops essential for fintech developmentnimbleappgenie
 
Usability Evaluation Techniques for Agile Software Model
Usability Evaluation Techniques for Agile Software Model Usability Evaluation Techniques for Agile Software Model
Usability Evaluation Techniques for Agile Software Model Saad, Ph.D (Health IT)
 
International Journal of Business and Management Invention (IJBMI)
International Journal of Business and Management Invention (IJBMI)International Journal of Business and Management Invention (IJBMI)
International Journal of Business and Management Invention (IJBMI)inventionjournals
 
The Four Prerequisites For DevOps Success
The Four Prerequisites For DevOps SuccessThe Four Prerequisites For DevOps Success
The Four Prerequisites For DevOps SuccessPMOfficers PMOAcademy
 
Ch22-Software Engineering 9
Ch22-Software Engineering 9Ch22-Software Engineering 9
Ch22-Software Engineering 9Ian Sommerville
 
Leveraging software-reuse-with-knowledge-management-in-software-development
Leveraging software-reuse-with-knowledge-management-in-software-developmentLeveraging software-reuse-with-knowledge-management-in-software-development
Leveraging software-reuse-with-knowledge-management-in-software-developmentDimitris Panagiotou
 
Information Technology Project Management - part 05
Information Technology Project Management - part 05Information Technology Project Management - part 05
Information Technology Project Management - part 05Rizwan Khurram
 
Archibald di filippo_comprehensive_plc_model_final
Archibald di filippo_comprehensive_plc_model_finalArchibald di filippo_comprehensive_plc_model_final
Archibald di filippo_comprehensive_plc_model_finalsansharmajs
 
A PROPOSED HYBRID AGILE FRAMEWORK MODEL FOR MOBILE APPLICATIONS DEVELOPMENT
A PROPOSED HYBRID AGILE FRAMEWORK MODEL FOR MOBILE APPLICATIONS DEVELOPMENT A PROPOSED HYBRID AGILE FRAMEWORK MODEL FOR MOBILE APPLICATIONS DEVELOPMENT
A PROPOSED HYBRID AGILE FRAMEWORK MODEL FOR MOBILE APPLICATIONS DEVELOPMENT ijseajournal
 
BEST PRACTICES FOR IMPROVING USER INTERFACE DESIGN
BEST PRACTICES FOR IMPROVING USER INTERFACE DESIGN BEST PRACTICES FOR IMPROVING USER INTERFACE DESIGN
BEST PRACTICES FOR IMPROVING USER INTERFACE DESIGN ijseajournal
 
Scct2013 topic6-integrative mediaprojectdevelopment
Scct2013 topic6-integrative mediaprojectdevelopmentScct2013 topic6-integrative mediaprojectdevelopment
Scct2013 topic6-integrative mediaprojectdevelopmentAnies Syahieda
 
Promoting knowledge sharing in projects
Promoting knowledge sharing in projectsPromoting knowledge sharing in projects
Promoting knowledge sharing in projectsLouise Worsley
 

What's hot (19)

Why is dev ops essential for fintech development
Why is dev ops essential for fintech developmentWhy is dev ops essential for fintech development
Why is dev ops essential for fintech development
 
Usability Evaluation Techniques for Agile Software Model
Usability Evaluation Techniques for Agile Software Model Usability Evaluation Techniques for Agile Software Model
Usability Evaluation Techniques for Agile Software Model
 
Siemens plm-key ox-industrial-design-cs-z5
Siemens plm-key ox-industrial-design-cs-z5Siemens plm-key ox-industrial-design-cs-z5
Siemens plm-key ox-industrial-design-cs-z5
 
50120130406031
5012013040603150120130406031
50120130406031
 
Hci practices-in-agile-software-development
Hci practices-in-agile-software-developmentHci practices-in-agile-software-development
Hci practices-in-agile-software-development
 
International Journal of Business and Management Invention (IJBMI)
International Journal of Business and Management Invention (IJBMI)International Journal of Business and Management Invention (IJBMI)
International Journal of Business and Management Invention (IJBMI)
 
Agile development
Agile developmentAgile development
Agile development
 
The Four Prerequisites For DevOps Success
The Four Prerequisites For DevOps SuccessThe Four Prerequisites For DevOps Success
The Four Prerequisites For DevOps Success
 
Collaborative technologies
Collaborative technologiesCollaborative technologies
Collaborative technologies
 
Ch22-Software Engineering 9
Ch22-Software Engineering 9Ch22-Software Engineering 9
Ch22-Software Engineering 9
 
Leveraging software-reuse-with-knowledge-management-in-software-development
Leveraging software-reuse-with-knowledge-management-in-software-developmentLeveraging software-reuse-with-knowledge-management-in-software-development
Leveraging software-reuse-with-knowledge-management-in-software-development
 
Vb ch 1-introduction
Vb ch 1-introductionVb ch 1-introduction
Vb ch 1-introduction
 
Information Technology Project Management - part 05
Information Technology Project Management - part 05Information Technology Project Management - part 05
Information Technology Project Management - part 05
 
Archibald di filippo_comprehensive_plc_model_final
Archibald di filippo_comprehensive_plc_model_finalArchibald di filippo_comprehensive_plc_model_final
Archibald di filippo_comprehensive_plc_model_final
 
A PROPOSED HYBRID AGILE FRAMEWORK MODEL FOR MOBILE APPLICATIONS DEVELOPMENT
A PROPOSED HYBRID AGILE FRAMEWORK MODEL FOR MOBILE APPLICATIONS DEVELOPMENT A PROPOSED HYBRID AGILE FRAMEWORK MODEL FOR MOBILE APPLICATIONS DEVELOPMENT
A PROPOSED HYBRID AGILE FRAMEWORK MODEL FOR MOBILE APPLICATIONS DEVELOPMENT
 
Ch22 project management
Ch22 project managementCh22 project management
Ch22 project management
 
BEST PRACTICES FOR IMPROVING USER INTERFACE DESIGN
BEST PRACTICES FOR IMPROVING USER INTERFACE DESIGN BEST PRACTICES FOR IMPROVING USER INTERFACE DESIGN
BEST PRACTICES FOR IMPROVING USER INTERFACE DESIGN
 
Scct2013 topic6-integrative mediaprojectdevelopment
Scct2013 topic6-integrative mediaprojectdevelopmentScct2013 topic6-integrative mediaprojectdevelopment
Scct2013 topic6-integrative mediaprojectdevelopment
 
Promoting knowledge sharing in projects
Promoting knowledge sharing in projectsPromoting knowledge sharing in projects
Promoting knowledge sharing in projects
 

Similar to White paper - Adhoc 2.0

Extending Agile to Suite Big Projects
Extending Agile to Suite Big ProjectsExtending Agile to Suite Big Projects
Extending Agile to Suite Big ProjectsAmin Bandeali
 
Agile Methodology For Software Development
Agile Methodology For Software DevelopmentAgile Methodology For Software Development
Agile Methodology For Software DevelopmentDiane Allen
 
An Introduction to Agile Software Development
An Introduction to Agile Software DevelopmentAn Introduction to Agile Software Development
An Introduction to Agile Software DevelopmentSerena Software
 
Agile project management and normative
Agile project management and normativeAgile project management and normative
Agile project management and normativeGlen Alleman
 
A Systematic Study On Agile Software Development Methodlogies And Practices
A Systematic Study On Agile Software Development Methodlogies And PracticesA Systematic Study On Agile Software Development Methodlogies And Practices
A Systematic Study On Agile Software Development Methodlogies And PracticesSean Flores
 
Introducton of event-driven edited.pptx
Introducton of event-driven edited.pptxIntroducton of event-driven edited.pptx
Introducton of event-driven edited.pptxkristinatemen
 
Adaptive software development (asd) a minimalist approach to complex software...
Adaptive software development (asd) a minimalist approach to complex software...Adaptive software development (asd) a minimalist approach to complex software...
Adaptive software development (asd) a minimalist approach to complex software...Katy Slemon
 
Interaction Room - Creating Space for Developments (Software Projects)
Interaction Room - Creating Space for Developments (Software Projects)Interaction Room - Creating Space for Developments (Software Projects)
Interaction Room - Creating Space for Developments (Software Projects)adesso Turkey
 
Ieee sw small_projects
Ieee sw small_projectsIeee sw small_projects
Ieee sw small_projectsmanoharbalu
 
Software engineering project management
Software engineering project managementSoftware engineering project management
Software engineering project managementjhudyne
 
Agile introduction for dummies
Agile introduction for dummiesAgile introduction for dummies
Agile introduction for dummiesVinay Dixit
 
Improving software economics - Top 10 principles of achieving agility at scale
Improving software economics - Top 10 principles of achieving agility at scaleImproving software economics - Top 10 principles of achieving agility at scale
Improving software economics - Top 10 principles of achieving agility at scaleIBM Rational software
 
Google's Innovation Factory (ICST 2010)
Google's Innovation Factory (ICST 2010)Google's Innovation Factory (ICST 2010)
Google's Innovation Factory (ICST 2010)Go Ku
 

Similar to White paper - Adhoc 2.0 (20)

Agile methodology
Agile methodologyAgile methodology
Agile methodology
 
Extending Agile to Suite Big Projects
Extending Agile to Suite Big ProjectsExtending Agile to Suite Big Projects
Extending Agile to Suite Big Projects
 
ETPM5
ETPM5ETPM5
ETPM5
 
Agile Methodologies & Key Principles
Agile Methodologies & Key Principles Agile Methodologies & Key Principles
Agile Methodologies & Key Principles
 
Agile Methodology For Software Development
Agile Methodology For Software DevelopmentAgile Methodology For Software Development
Agile Methodology For Software Development
 
An Introduction to Agile Software Development
An Introduction to Agile Software DevelopmentAn Introduction to Agile Software Development
An Introduction to Agile Software Development
 
Agile project management and normative
Agile project management and normativeAgile project management and normative
Agile project management and normative
 
H017245157
H017245157H017245157
H017245157
 
What is Agile Development?
What is Agile Development?What is Agile Development?
What is Agile Development?
 
A Systematic Study On Agile Software Development Methodlogies And Practices
A Systematic Study On Agile Software Development Methodlogies And PracticesA Systematic Study On Agile Software Development Methodlogies And Practices
A Systematic Study On Agile Software Development Methodlogies And Practices
 
Introducton of event-driven edited.pptx
Introducton of event-driven edited.pptxIntroducton of event-driven edited.pptx
Introducton of event-driven edited.pptx
 
Poor Man's Kanban
Poor Man's KanbanPoor Man's Kanban
Poor Man's Kanban
 
Adaptive software development (asd) a minimalist approach to complex software...
Adaptive software development (asd) a minimalist approach to complex software...Adaptive software development (asd) a minimalist approach to complex software...
Adaptive software development (asd) a minimalist approach to complex software...
 
Interaction Room - Creating Space for Developments (Software Projects)
Interaction Room - Creating Space for Developments (Software Projects)Interaction Room - Creating Space for Developments (Software Projects)
Interaction Room - Creating Space for Developments (Software Projects)
 
Ieee sw small_projects
Ieee sw small_projectsIeee sw small_projects
Ieee sw small_projects
 
Software engineering project management
Software engineering project managementSoftware engineering project management
Software engineering project management
 
Agile introduction for dummies
Agile introduction for dummiesAgile introduction for dummies
Agile introduction for dummies
 
Software developer
Software developerSoftware developer
Software developer
 
Improving software economics - Top 10 principles of achieving agility at scale
Improving software economics - Top 10 principles of achieving agility at scaleImproving software economics - Top 10 principles of achieving agility at scale
Improving software economics - Top 10 principles of achieving agility at scale
 
Google's Innovation Factory (ICST 2010)
Google's Innovation Factory (ICST 2010)Google's Innovation Factory (ICST 2010)
Google's Innovation Factory (ICST 2010)
 

More from Nuno Brito

Triplechecheck induction-presentation-sample
Triplechecheck induction-presentation-sampleTriplechecheck induction-presentation-sample
Triplechecheck induction-presentation-sampleNuno Brito
 
2014 10-14: GitHub plus FOSS == 1 million SPDX
2014 10-14: GitHub plus FOSS == 1 million SPDX2014 10-14: GitHub plus FOSS == 1 million SPDX
2014 10-14: GitHub plus FOSS == 1 million SPDXNuno Brito
 
Ubucon 2013, licensing and packaging OSS
Ubucon 2013, licensing and packaging OSSUbucon 2013, licensing and packaging OSS
Ubucon 2013, licensing and packaging OSSNuno Brito
 
Stop look and listen before you talk
Stop look and listen before you talkStop look and listen before you talk
Stop look and listen before you talkNuno Brito
 
Lifes Good In Portugal
Lifes Good In PortugalLifes Good In Portugal
Lifes Good In PortugalNuno Brito
 
Managing business relationships
Managing business relationshipsManaging business relationships
Managing business relationshipsNuno Brito
 
Explaining the WinBuilder framework
Explaining the WinBuilder frameworkExplaining the WinBuilder framework
Explaining the WinBuilder frameworkNuno Brito
 

More from Nuno Brito (7)

Triplechecheck induction-presentation-sample
Triplechecheck induction-presentation-sampleTriplechecheck induction-presentation-sample
Triplechecheck induction-presentation-sample
 
2014 10-14: GitHub plus FOSS == 1 million SPDX
2014 10-14: GitHub plus FOSS == 1 million SPDX2014 10-14: GitHub plus FOSS == 1 million SPDX
2014 10-14: GitHub plus FOSS == 1 million SPDX
 
Ubucon 2013, licensing and packaging OSS
Ubucon 2013, licensing and packaging OSSUbucon 2013, licensing and packaging OSS
Ubucon 2013, licensing and packaging OSS
 
Stop look and listen before you talk
Stop look and listen before you talkStop look and listen before you talk
Stop look and listen before you talk
 
Lifes Good In Portugal
Lifes Good In PortugalLifes Good In Portugal
Lifes Good In Portugal
 
Managing business relationships
Managing business relationshipsManaging business relationships
Managing business relationships
 
Explaining the WinBuilder framework
Explaining the WinBuilder frameworkExplaining the WinBuilder framework
Explaining the WinBuilder framework
 

White paper - Adhoc 2.0

  • 1. Ad hoc 2.0 – The New Generation Nuno Brito CMU/UC Master of Software Engineering 2009/2010 Managing Software Development nbrito@andrew.cmu.edu Abstract long time as essential to improve the odds of success for a professional project in the software industry [4]. Ad hoc software development is the construction of software solutions through methods and techniques However, with the advent of massive access to the that are most often developed from scratch during Internet came the emancipation of end-users, providing project development. Although a reputation of limited the conditions that allowed them to evolve from a flexibility and scalability haunts this methodology, it is passive state onto active positions inside the project as nevertheless a powerful technique to build and deploy beta-testers or even becoming active developers that applications or prototypes within a short period of help to carry forward the progress and lead the project time. to success. The power of this type of cooperative Ad hoc will not scale in the traditional format that is development is well described by Eric S. Raymond in known to software engineers, but web 2.0 platforms “The Cathedral and the Bazaar” [5]. such as forums, blogs and social networks combined with accessible development frameworks are now The Internet thrives at a web 2.0 era as a global reviving the ad hoc philosophy as a valid approach to platform that is reachable to a far wider stream of the developers where this scaling/complexity limitation is population when compared to web 1.0. People from not an obstacle anymore. Even thought it is not a any gender, age or technical background can magic bullet that can solve the issues that arise from effectively communicate, work, produce and share avoiding a more complete and formal methodology, knowledge on a global scale with a relative ease. There this is nevertheless a growing and attractive trend is an emergent new generation of software projects that amongst many small sized software projects to produce follow the old ad hoc approach principles but are no software capable of rivaling side by side commercial longer tied to a restricted group of people involved into applications from professional developments, resulting development with a high level of knowledge on in what we define as Ad Hoc 2.0 – The new generation. professional programming activities [2]. On this paper, we will begin by focusing on the way how ad hoc is currently perceived from a professional 1. Introduction perspective and then perform a more in depth analysis to attempt understanding the advantages and Where does the term Ad hoc come from? disadvantages that arise from this methodology when Ad hoc is a Latin phrase which means "for this contextualized inside a software engineering plan. [purpose]". It is a common practice to use this term for Later, we approach the concept of Ad hoc 2.0 from a describing specific solutions applied to a given task or high level perspective that explores the reasons why problem which cannot be generalized or adapted to it’s use is made possible and attempt to identify other purposes. common life cycles that projects following this In the context of software development, an ad hoc methodology might eventually follow. We will then methodology is often associated to a short life cycle focus on real examples of projects built and maintained span, or even to the lack of architecture that addresses with some success while employing this methodology scalability and completeness since the early project to some extent and analyze some of the characteristics inception. These are characteristics recognized since a that can either lead to success or failure the future of a project in terms of longevity and large scale software development.
  • 2. since its inception, but a development process is also Before we start dwelling onto the definitions between driven from the developer’s talent and effort which ad hoc in the traditional format and the new format that tends to avoid formalized processes that present is the topic of this paper, it should be noted that there restrictions to creativity and innovation [13]. When are some ambiguities regarding the terms: “life cycle”, integrated at an open and global market environment “methodology” and “process” related to the where innovation and competition are more often than development of projects. not the aggressive points that help to establish success [7], can we continue to assume as a correct to regard ad The author will adopt a consistent and contextualized hoc approaches in such negative manner to the point of definition of each term throughout the paper in order to software engineers completely discard them as an ease its overall meaning at each paragraph. To help efficient solution for professional software industry clarify what each term is usually referred to, some products? explanation about each term is due: “Process” refers to the tasks that are executed inside each phase of The criticism mentioned on CMMI about the development. “Methodology” refers to the set of precarious style of developing software is certainly true techniques and methods that are employed on these in most of it’s extent, but it is also true that software processes. “Life cycle” is referring to all phases of the developers still apply ad hoc in their everyday work as project since it’s early inception until it’s final state of an intuitive and efficient way to manage the resources release of the product to the customer including available to them. This is an approach that allows a posterior phases (if any) as help desk support and project in a real world of software competition where maintenance for example. high levels of creativity under a tight budget of time and resources become so critical as necessary to survive. 2. Traditional Ad Hoc development The most interesting force that drives ad hoc as a compelling approach is the (in)famous preference for a 2. 1. Concept lack of formal processes since the early inception of the project. There is a common misconception that ad Software engineering often tends to consider Ad hoc hoc followers do not follow any formalized process, with a negative impression when it comes to choose a the truth lies in the fact that an ad hoc project will life cycle solution against a formal approach. simply be developed without a specific process methodology followed from a strict and formal manner SEI (Software Engineering Institute), characterizes since the beginning. Eventually, some formal processes ad Hoc in “CMMI for development” [10] as a do tend to surface after they are tested and considered methodology belonging to the lowest possible level: as fit to the custom needs of the project in question but “At maturity level 1, processes are usually ad hoc and this misconception might lead assumptions that chaotic. The organization usually does not provide a characterize the overall development as “hackish” or stable environment to support the processes. Success in even as “chaotic” when viewed from an external these organizations depends on the competence and perspective that is not aware of how these formal heroics of the people in the organization and not on the processes are unique to the project in question even if use of proven processes. In spite of this chaos, maturity they don’t follow a standardized approach. level 1 organizations often produce products and services that work; however, they frequently exceed Using nothing more than know-how from the team of their budgets and do not meet their schedules. Maturity developers mixed with experience acquired during the level 1 organizations are characterized by a tendency project’s life cycle, an ad hoc project can ensure in to over commit, abandonment of processes in a time of most cases that whatever processes are adopted along crisis, and an inability to repeat their successes.” the development cycle, they will eventually be modified enough to the point of sufficing the needs of Formal methodologies will often attempt to follow a the project to some extent. The level of efficiency predefined set of stages intended that provide a certain resulting from these ongoing ad hoc processes is quality level and management control, in some cases, perhaps questionable as it will depend directly from the even allow certification of their software practices proficiency and talent of the team elements or even from a third party entity. These are recognizable derive from user feedback that helps them to be characteristics for a well engineered product that is elaborated. This is an approach that carries advantages aimed to reach a higher level of CMMI maturity [10]
  • 3. and disadvantages that will be explored over the next on ad hoc as an approach to allow exploring section. competitive solutions on the market that allows to quick releases to public and outperform competitors. 2.2. Advantages and Pitfalls We can identify and detail some of the reasons for this negative fame: Ad hoc still holds several advantages as a development • Poor practice of requirements’ elicitation - no approach since it is well adjusted for projects of predefined set of procedures to properly relatively small to medium dimension that can be made conduct a requirements elicitation process that available when time and expected results don't justify allows understanding the scope of a given the cost of instantiating a formal process. problem. Raising the risk that a given project can drive a team to waste efforts on solving For example, ad hoc approaches are very well applied superficial symptoms instead of actually to cases where a given project requires a proof of solving the reason that causes the problem or concept before engaging onto a full scale development even mixing requirements with a possible following a formal approach, or perhaps applied to solution. projects that are meant for internal use, where customer, developers and end-users all belong to the • Quality assurance is not measured nor same company and a formal process is considered to conducted efficiently - without using an add unnecessary overhead to deliver the product. efficient strategy for early defect detection or procedures to continuously assess overall Ad hoc can sustain a high level of motivation and quality through methods such as Fagan interest from a team since it allows developing a inspections [12], a high density of defects will project in a light-weight manner that is intended for eventually be discovered after releasing the release within a short term of time, this is a good initial product version to the customer. manner to promote innovation and creativity to take place without too many barriers to development, • Lack of scalability or generality, ad hoc however, allowing a project to be developed without projects focus their target to a specific formal methodologies and depending solely on the audience with specific needs. This experience from developers is also a risk that raises the characteristic will constraint since the initial odds of impact from several disadvantages that need to days of development the range of evolution be considered before engaging into this sort of practice. that can be expected in terms of scope, size and complexity when planning to grow in all What specific reasons keep companies away from these dimensions. We'll explore this particular adopting Ad Hoc? characteristic over the next section of this paper. Ad hoc inherited a very negative image since the 90’s. This is the worse factor that still prevents at present its 2.3. Scalability of ad hoc projects official adoption by professional software developers. It will also remain as the cause to which people will Scalability is an often desired characteristic on point their finger when looking for a reason to blame commercial projects that seek a growing number of for a never-ending appearance of problems that arise end-users as it might bring a proportional growth in when the inherent limitations to this approach are not revenue. But if the base of end-users grows properly understood. This approach suffers from the continuously over time, the project will also tend to same type of issue often associated to companies who inevitably increase in size and complexity. As result, avoid XP or generic Agile methodologies after passing features will be added, exposed defects will require through negative experiences due to their initial lack of correction, support for end users and legacy experience in the agile approach to begin with. This maintenance for older versions will need to be same factor inducts a catch-22 type of problem where a provided in a scale that will surely continue increasing. company that publicly admits to use ad hoc on their projects will suffer to pass onto the outside world an Scalability will therefore impact the development image where quality and efficiency are not perceived resources that were originally allocated to a given as reliable, thus causing impact on the reputation, but ongoing project [1]. Ad hoc is rarely prepared to the underneath the hood, the same company can still rely endurance of time and increase of user base over long
  • 4. terms of time. A project based on ad hoc architecture will demonstrate it's inadequacy to survive as Open source projects are most often characterized as a complexity increases, often requiring a complete geographically disperse group of volunteer developers rebuild from the ground up to match the expected level that enlist themselves to aid at tasks suited for their of usage and efficiency - perhaps even employing a talent which eventually keep a project moving forward formal process to achieve the intended results for the on a good level of progress if it retains the attention of future and no longer be labeled as ad hoc. an audience. The popularity, influence and success of a given open source project can therefore be directly These are the most common reasons why companies measured in most cases by the number of users and choose a formal development process from the start. volunteers that work to ensure it's long term longevity. Characteristics such as scalability and maintainability over the long term are planned right from the early The approach for developing these projects when they project inception and the gain from a quick start and are small sized can be loose and sporadic. But when delivery as provided by ad hoc will only come with these projects start growing across several dimensions higher costs to solve as the project itself grows bigger. such as complexity and user base - then a natural Even thought the bad reputation assigned to ad hoc can tendency to adopt a strict and formal set of sometimes be considered as exaggerated since people methodologies that allow a team to keep the overall tend to pick examples where it is certainly not an processes of development under control will eventually appropriate approach, the truth is that its limitations in begin to surface. the traditional format are both a blessing and course that will limit its usage to developers with significant So, we can conclude that regardless of the nature from experience in the software industry to take advantage a given software product being open source or closed of most benefits it has to offer without suffering most source, if the dimension of this project belongs to mid of the recognized pitfalls. or large size and complexity then it will eventually need to increase the control over the processes for However, a new generation of ad hoc is surfacing that developing software in the long term if the overall does not require an extensive experience on software project’s goal is to remain active and popular. development nor is limited to the same boundaries of the traditional ad hoc format as before. We will now Traditional Ad hoc usage can be found necessary to introduce this new concept over the next section. kickstart a project that follows either the open or closed source type of methodology, we also mentioned previously that exists a natural evolution of a project to 3. Ad hoc 2.0 – The New Generation somehow expect a progressive formalization of the ad hoc processes to also occur if enough time is given. It is a fact that the Internet plays an important role as Or, in more extreme situations, the developers from an communication platform for people that wouldn't initially ad hoc project can decide to redesign it from otherwise group together. scratch, using then the formal methods that are more This access to the Internet world influenced the appropriate to generate a new architecture based on software development paradigm as reported by Eric S. lessons gathered from past experience on the Raymond in “The Cathedral and the Bazaar” [5]. development effort. Failing to evolve onto this However, Eric’s study is mainly focused on the formalized phase of development might eventually contrasting differences from closed source projects lead a project to stagnation or increase the risk of compared to open source movements and leaves out becoming overrun by other competing projects. some of the interesting management techniques that allowed ad hoc processes to efficiently manage We can therefore infer that a project cannot use resources in large scale software development projects. traditional ad hoc methodologies as a sustainable solution for a long term of time and this fact remained Both open and close source movements share concerns as a solid truth since a long time ago. But when ad hoc that are similar to some extent about the question of meets the Internet of masses, an exciting new twist on human managing, quality control and customer the fate of ad hoc projects allows breaking this rule. satisfaction even thought they are following different approaches regarding the way how software should be The audience of users interested in joining efforts to developed. help a given project for absolutely no cost allows people to organize themselves and develop a project by
  • 5. voluntarily assuming the responsibilities of specific developers can effectively rival against products roles inside these ad hoc processes. Groups of people developed from commercial companies or provide will form effective development teams that can per solutions that wouldn’t otherwise be explored by times outperform professional developers. This can be commercial groups. due to the high level of motivation and feedback from multiple perspectives provided by direct contact Ad hoc 2.0 projects have no roadmaps defined for each between end-users and product developers. People development phase and can often be defined as an involved in ad hoc 2.0 projects will usually share the ongoing development work whose progress is based on same domain knowledge in a similar manner to what volunteers and continuous feedback from users. currently occurs with open source movements. 3.1. Typical life-cycle of an Ad Hoc 2.0 project There are situations were this type of ad hoc is the ideal situation for decentralized development without What can be expected from Ad Hoc 2.0? requiring a high level of control or management. When efforts are based on cooperative work from volunteers This is a flexible approach. There is no structure that that are not confined to a strict and formal organization can accurately describe a similar pattern across projects as noted on many open source movements of bigger of this particular kind, nevertheless, it is possible to dimension, development will become intuitive and distinguish a few phases that are likely to occur during dynamic, adapting more easily to the newer trends of the project lifetime. technology without added costs. This type of specific volunteer movement can be found across many other The ideal team development condition to allow projects of small dimension whose code is not forming an Ad hoc 2.0 approach are situations where necessarily released to the public but where people still only a single developer or a small number of offer their time and talent to help in tasks such as developers between 2 up to 5 elements are included. language translation, beta testing, help desk support or There may exist several team elements assigned with whichever tasks required. secondary roles such as beta testers and such, but the primary team elements should always be responsible There is an ongoing trend where the exclusive use of for the most important decisions regarding the project web 2.0 technologies such as bulletin boards, blogs or progress while sharing the role of end-users on the any other social networks will allow people across the same project. globe to communicate and share knowledge between them. These are the ideal locations where an ad hoc The lifecycle for an Ad hoc 2.0 project will typically project can progress and reach popularity with the follow 5 distinct phases of development. increase of users and complexity while withstanding the test of time without ever requiring the move onto 1. Idea – The concept for a given project is more formalized practices as seen in the traditional ad proposed by a developer or small group of hoc format. developers to solve a given problem or challenge. A brainstorm session between There is no extensive roadmap, no architecture plan is some of the stakeholders occurs and attempts detailed, no monitoring of milestones nor extensive to identify possible competitors, alternatives quality control is conducted, and yet, these are projects and involved complexity to carry forward the that still manage to provide a product or service that project onto a feasible success. reaches success and even outperform professional developments under some situations. This is what we 2. Implementation – The project begins identify as “Ad hoc 2.0 – the new generation”. implementation shortly after the idea is accepted as achievable. The project will likely It's a concept for developing software where some of be coded using a software framework that is the common disadvantages identified from traditional familiar to the developers. ad hoc are eventually solved or not even considered relevant to some extent. There is an important human 3. Initial version – A first version is made value that is raised from this mass number of users that available to the public as proof of concept that allows these projects to keep moving forward the innovating idea for the project can be regardless of their complexity. These projects can be achieved. Usually released to a small group of based solely on the help and talent from volunteers. It’s people that are close to the development circle the type of methodology where small groups of in order to gather feedback.
  • 6. development of the project; 4. Revision / Beta versions – Incremental beta 7. Easy to manage– doesn't require team releases and versions considered as stable are elements to posses a specific formal published to address bugs or requested education on software development and features. Very active participation of end- management, a small team is capable of users in this stage. develop a good product using common good sense to solve most situations; 5. Stagnation – A project eventually reaches a 8. Lightweight – can be instantiated in a state of inactivity and either doesn’t fulfill short period of time and keep the requests from end-users or there is not enough motivation of the involved developers at interest from the community where it is a very high level of engagement as the discussed to provide additional feedback. project results are visible very quickly; Stagnation occurs since the project 9. High number of versions released to the development is neither announced as public that address new features or terminated nor the responsible developers will defects fixes; provide insightful news regarding the project 10. Development driven by user feedback, progress in the future. progress occurs according to motivation of authors and user base requests. If a 3.2. Advantages and disadvantages project is popular then it might act as a good motivator for the author to proceed Ad hoc 2.0 under this new context remains truthful to with further development; it's origins – avoid formal processes from the beginning, change and adapt as necessary in order to And also some disadvantages: survive. To avoid an extensive list of characteristics, we narrowed the scope down to 10 advantages and 10 1. It's not prepared to scale or handle disadvantages that seem relevant to expose on this complexity by default, the effort required particular development methodology. to adapt onto a bigger user base or code complexity might be overwhelming for a Advantages that are commonly found: small development team; 2. No formalized quality assessment as 1. Good for volunteer work as people can there are no repeatable processes to join at any given time as beta testers or ensure that the project development even developers in some situations; doesn't cause conflicts with previous 2. Well adjusted to small sized projects as development effort [12]; the level of complexity can still be 3. No metrics defined to evaluate project completely manageable by a single status makes the task of tracking progress developers or small team of developers; more difficult to understand by everyone 3. Allows to build strong relationships with involved in the project; users since they also become an active 4. Risks are often not clearly explored and part of the development process as beta analyzed before proceeding with project testers or other roles to which they development, this might force developers volunteer and help the project effort to deal with unexpected risks that could move forward; have been avoided from the start; 4. Affordable – requires few resources since 5. No clear milestones with well defined inception and the development team can goals as the project is governed by the in most of the cases work on the project specific needs at any given time. during his free time as a hobby; Defining milestones is a very difficult 5. Localized – solves an immediate need of task unless there is a clear goal to achieve a specific audience instead of requiring from the beginning; support for a much wider array of 6. Requirements' elicitation is often possible users; incomplete as developers tend to opt by 6. Flexible – adjusts well to new delivering a quick fix or patch to solve requirements that may appear during the symptoms of a problem without development or to new situations that focusing on the reason that is causing it in may cause a significant drift on the the first place.
  • 7. 7. No schedule is usually defined in most level of built-in functionality that wouldn’t otherwise cases as the project progress will depend allow these small sized teams to quickly produce on the effort and motivation from the applications based on already built user interfaces and developers, which might lead to many other components that are stable and allow them prolonged states of stagnation; to focus efforts on innovation. 8. High rate of bugs since new versions are often released to public without extensive In order for a given project to achieve a competitive debugging care and often rely on user level and maintain this position, the software processes feedback to detect defects and prioritize that are employed should also be based on flexibility their fix. and extensibility rather than high quality as mentioned 9. Defects are not reported with enough by Nogueira in “Surfing the edge of chaos”[11]. The details because users are not properly goal is to maintain a balance between innovation and trained for this task, often leading to public interest. Assuming that an ad hoc methodology ambiguous or incomplete reports about a allows a project to reach the top of it's initial defect that needs to be corrected. expectations and is well adjusted to keep a large 10. Too many different versions are difficult percentage of users happy with the product for a long to use and might even paralyze any effort period of time, then there is an important question that to bring simplicity into a version system needs to be asked: where can software engineering be that attempts to distinguish between found under this new paradigm? stable and unstable versions of the product. We devote the next section to clarify this question and the implications of processes when viewed from a Previously, Ad hoc methods would be found applied software engineering perspective. mostly to software built with the focus on a specific target audience, the “users by the dozens” [4]. Access 3.3. Surviving to scalability and long-term to the Internet allowed this specific target audience to development become amplified from mere dozens to hundreds or even thousands of users on daily basis. The most desired characteristic in Ad hoc 2.0 projects is a successful transition to a higher scale of work and This difference in the scale of masses places Ad hoc in complexity that allows supporting a wide number of a privileged position as most of the costs from users and developers while increasing the overall development and research can be reduced to a few quality of services that are made available by the single developers with talent. Success is often project. Failing to evolve into a more adapted measured by the amount of people who follow their architecture for the project will eventually lead the progresses and this is probably the way how software overall development into a situation where the project development can achieve its most emphatic form: a will no longer be able to keep up with other competing state of coding where the gap between developer and projects. end-users of the project is reduced to a bare minimum. Software Engineering should be employed to explore This flexibility to release a product often allows more efficient engineering methodologies that are publishing several minor version updates as prototypes capable of producing processes adapted to a certain that help developers get a better notion of the ideal type of project and this same engineering practice now product that answers the ever changing expectations becomes necessary to ensure that this trend of software from end-users. This type of approach often requires an development can learn how to safely evolve onto a uncertain number of releases and it’s very difficult to more balanced level of development progress. perform estimations or assessing the overall project status but these are also factors that assume a smaller A transition from an ad hoc approach onto a formalized or less critical relevance in this context. life cycle where processes, architecture and vision for the project are already defined in advance is not an The recent software development frameworks are also easy task [14]. In order to understand how this responsible in part for the existence of this new approach should be executed, it is necessary to look on generation of developers. Powerful frameworks are in real examples from projects that somehow pioneered most cases offered at no cost for developers (Eclipse, the path for this thriving Ad hoc 2.0 philosophy, Visual Studio) as the companies who develop them strongly focused on the power of community work and have also interest in their mass adoption, and provide a
  • 8. attempt to understand some of the possible outcomes depends on a single developer, Dino Nuhagic, which for the future, even risking to never actually move onto released the initial version in April 2004. This product a state where formalized processes can be safely was an immediate success ever since the initial release. implemented with success. Thought buggy, it would still allow users to save a considerable amount of time that was previously required to customize a given Microsoft Windows 4. Case Studies installation source. The project's development space for discussion was One of the most seductive advantages of Ad Hoc provided by MSFN (http://msfn.org) – a forum development is the freedom to create and quickly dedicated to the discussion of windows based releases to the public a working version of the project technology that was already popular at the time of that ensures enough innovation and chaos will provide nLite's presentation to public. At that time, this forum encouragement for volunteers to help and motivate the counted with an average of 342 visitors at each 30 developers into further progress. minutes. Using this site as base for discussing and presenting incremental versions of the product, nLite People developing a software product on their free grew onto a user base of thousands over the initial 12 time and publishing it on the Internet will instinctively months, reaching a state of recognized quality when it be adopting an Ad hoc 2.0 lifestyle without necessarily began being referenced by Microsoft in the official becoming aware of their selection and inherent knowledge base support channels. consequences in most cases. It is important to promote the investigation and elaboration of studies that allow Remaining as a one-man-project, nLite evolved onto to capture and understand some of the magic behind vLite as the Microsoft Windows Vista Operative this seemingly chaotic group of processes that seems System was launched. When the family of software nevertheless be working because of the human factor, products developed by this author began increasing in exactly as described previously by the CMMI. terms of overall complexity aggravated by a significant amount of new features added to each recent version, Therefore, ad hoc is a human instinct approach, a these factors began to toll a visible weight on the specialized management technique that is applied development effort. The author decided to cease whenever processes seem to add excessive overhead, development and declared product freeze in early 2008 are unknown to developers or fail to meet a given at the peak of its popularity. Support to the products is efficiency criteria – as mentioned before, even newer still provided on volunteer basis at the forums but it is software products can be released using this particular grows increasingly outdated as the products do not lifecycle as method to bootstrap them and evaluate keep up with the newer released Microsoft Windows 7 their prospective popularity before engaging into a and allows other competitors to compete for filling the more formal development style. void left by a possible 7lite in the future. As examples to showcase this style of development, What happened? three competing software products designed for the Microsoft Windows platform were chosen. They all Too many arguments can be formulated regarding the started as products created by stand alone developers reasons why the project came to halt. The author that later evolved to large scale software systems due himself claimed the need for free time to engage in a to their expansion by components originated from third professional software development activity. A project party developers without direct relation to the with increasing complexity and user requests was development team in some cases. simply too much for a single person to support or one can also consider that at some given point after so 4.1 nLite many years, the author lost its initial motivation to pursue development of this project. nLite is a software product that allows users to customize or remove specific components from a given What we can infer is that in many aspects, this is still a Microsoft Windows XP/2003 install CD or Microsoft successful project today, but the fact that it remained as Windows Vista install DVD. It will also allow to a one-man-project was eventually a weak point that integrate updates, automate the installation process and allowed development freeze to occur. integrate third party programs [6]. Its development
  • 9. 4.2 Bart's PE Builder provided on the public forum by volunteers but the exposed defects and user requested features that remain BartPE (Bart's Preinstalled Environment) is a unanswered are a serious issue that undermines the lightweight variant of Microsoft Windows XP or attractiveness for users that now tend to adopt recent Windows Server Operative System which can be run Microsoft O.S. such as Microsoft Windows Vista and from a CD or USB drive [8]. It was developed by Bart Microsoft Windows 7. Lagerweij. The exact date of release for the first version is not simple to track but it was initially 4.3 WinBuilder published in the early months of 2003 [9]. The product was quickly marked with controversy at the time of WinBuilder began as a community spin-off from the launch. Microsoft was holding the monopoly for a 911cd.net forums into a brand new forum called Boot solution targeted to Windows system administrators, Land (http://boot-land.net) in mid 2005 [3] by a small the new Operative System platform designated as group of active users. This software project proposed Windows PE – which was only available as a to solve some of the issues and feature requests that commercially product to some organizations. BartPE were not addressed by Bart's PE Builder at the time. on the other hand, was offered completely for free and The main goal of WinBuilder is similar to BartPE allowed similar results without requiring a specific regarding the flexible customization of Windows PE license from MS. boot disks with emphasis in allowing that users can modify and improve the project, building components This free solution to the commercial Windows PE from top to bottom according to a given need. (WinPE) from Microsoft allowed to gather a significant number of end users, especially after Microsoft have This flexibility allows building extremely tailored boot no legal basis to contest the legal existence of BartPE, disks projects. With the appearance of subsequent which attracted considerable attention by the media. Microsoft Windows platforms, WinBuilder became a This alternative to WinPE was only deemed as legal by software framework for popular projects such as Microsoft as long as it would respect the Windows LiveXP, VistaPE and Win7PE. XP/2003 End User License Agreement (EULA). Flexibility in excess also originated negative In subsequent years, the product passed through 3 characteristics. Since each WinBuilder project is free major versions and enjoyed extensive popularity. The to define their own rules and organization, this ad hoc third and latest version of this product was released in approach causes a considerable lack of stable working February 2006 [8]. structures for developers to share code and knowledge across projects. Yet, development remains extremely BartPE counted with support from the 911 CD Builder active, based on volunteers that keep improving and forum (http://911cd.net/forums), a forum that was well providing updated versions of this software product known at the time for hosting other freeware developed and respective projects associated with it. projects related to the customization of boot disks based on MS Windows PE and MS DOS. Why is this working? The success of BartPE eventually eclipsed popularity Decentralized development is clearly present at the of all other projects hosted at the same forum across heart of this project. Each developer or team of the years that passed and become the official meeting developers doesn't depend exclusively on other point for BartPE users around the world. developers and if the development of a given project enters a freeze state – other volunteers can launch Unlike nLite, there was no successor of BartPE to the updated or even spin-off versions that eventually Windows Vista platform and this gap was filled with a provide a good degree of flexibility and progress that competitor project called VistaPE from Sergey outlives the initial author through other people that Gurinovich in early 2007. assume these positions in the development process. What happened? However, development processes have not yet been formalized nor seems to exist any plan to formalize The author stopped appearing on the public forums them. Even thought activity remains very visible across where his project was discussed and avoids replying the several components of the project, new challenges email messages regarding BartPE, leaving the project are typically solved using an Ad hoc approach. onto a development freeze state. Support is still
  • 10. 6. Conclusion 7. Acknowledgements This paper would have not been possible without the What can we learn from these examples? support, feedback and help from those across the Internet that embody this ad hoc 2.0 philosophy on All three projects shared the same concept of ad hoc daily basis without expecting more than a genuine and unplanned development. Supported by Internet “thank you” for their help to others. I’m grateful to websites frequented by masses of users from a specific have had the chance to meet some of these wise target audience, these projects enjoyed a suited internauts over the years and even observe from the platform that helped gather new users and extend the first row how these developments can truly succeed to longevity of both the website as the project itself. survive the test of time, scale and complexity. Would like to thank in particular to Jacopo Lazzari (Italy), This model of development is made possible even with Peter Schlang (Germany), TheHive (USA), Cemal scarce financial resources. Developers can code these Tolga Talas (Turkiye) and David Kummerow products as a hobby during their free time or secondary (Australia) for their inspiring contribution for this activity. Even thought the inception of a project first paper. occurs with the intent to solve a given challenge, these products can remain actively used for years to come as valuable working tools for thousands of users around the globe in years to follow. 8. References As seen on the Windows PE case, Microsoft provided 1. Dean F. Sutherland, “A Tale of Three Processes”: a commercial product to solve a particular market need Reflection on Software Development Process Change but was eventually driven to rethink their business at Tartan. model as the freely available alternatives succeeded in 2. Paul S. Adler, Beyond “Hacker Idiocy”: The gaining the market attention and momentum. Later Socialization Of Software Development. versions of Windows PE (since 2.x and above) are now 3. Nuno Brito, “WinBuilder”: Case study, 2009. made available for free for Microsoft Windows system 4. Clay Shirky, “Clay Shirky's Writings about the administrators. Internet”, March 2004. 5. Eric Steven Raymond, “The Cathedral and the This sort of community-based development is also Bazaar”, version 3.0, August 2002. present in open source movements but on the types of 6. Wikipedia cases in particular of software developments where the “http://en.wikipedia.org/wiki/NLite_and_vLite”, as source code is rarely made available to others, the seen on 21st of November 2009. project progress becomes extremely dependent from 7. Paine, Lynn Sharp & Royo, Jose. “Cimetrics the motivation of the original author unless some Technology” (A1)(9-399-108). Harvard Business balance can be reached to overcome this dependency. Online (2, February 1999), Paine 99 8. Wikipedia “http://en.wikipedia.org/wiki/BartPE”, as Software Engineering could have helped the first two seen on 21st of November 2009. projects presented on this case to survive the test of 9. Bart Lagerweij, time and continue to extend their popularity. Care “http://www.911cd.net/forums//index.php?showtopic= about the scalability of the project to newer Windows 837”, as seen on the 21st of November 2009. platforms or quality assessment techniques might have 10. CMU / SEI - “CMMI for Development” 2006. helped to simplify the overall software architecture if 11. Nogueira, et al. “Surfing the Edge of Chaos”: they had been considered since the beginning of Applications to Software Engineering, Naval development but this was no the case unfortunately. Postgraduate School. 12. Michael Fagan, “A history of software A single person using Ad hoc to develop a software inspections”: contributions to software engineering, product with the proper basis in software engineering Springer-Verlag New York, Inc., New York, NY, 2002 processes, awareness of this community power 13. Tom DeMarco & Timothy Lister, “Peopleware”: provided by web 2.0 technologies, the right amount of Productive projects and teams, Dorset Publishing motivation that establishes empathy with a target 14. Brooks, "No Silver Bullet”: Essence and Accidents audience, has all the right ingredients to achieve a very of Software Engineering, Computer, 10-19, Apr. 1987 satisfactory level of success for the future.