DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 5 of 5

Thread: Does anyone really use a software development process?

  1. #1
    Jim Jones Guest

    Does anyone really use a software development process?


    Over the last few years, I work for staffing/consulting firms and have been
    doing a lot of solo maintenance programming/support. As a result, my exposure
    to the latest formal design and development processes is fairly limited.
    I feel that I am good at solving problems and that I can write semi-decent
    source code, but when it comes to the more formal aspects of what I do now
    or will be expected to do on the next assignment (i.e. task estimation, requirements
    gathering and documentation, the ability to take a small software project
    from womb-to-tomb, etc.), I feel completely lost at times. Note: I am not
    a newbie to software development, however, my career path has been somewhat
    different from that of the stereotypical software developer in that I have
    never had a "breaking in period" and have always been expected to "do it
    all" so to speak.

    Up to this point, my approach or philosophy towards problem solving and software
    development has always been to simply use whatever tools and techniques that
    are available that will help do whatever it is that needs to done. Unfortunately,
    I have come to realize that in the enviroment in which I find myself working
    in (flying solo) that being able to solve problems and write source code
    simply isn't good enough. While I have been trying to come up with my own
    formal software development process, so far I haven't had much success.

    I have looked into RAD, iterative development, several of the agile (lightweight)
    and heavy (RUP) methodologies and while I like certain aspects of each one
    -- I don't think many of the ideas and techniques that they promote are well
    suited to independent software development.

    It appears to me that many of the well respected industry developers (i.e.
    book authors) have all developed their own methodologies. For example, Deborah
    Kurata has her GUID methodology, Paul Reed created the Synergy process, blah,
    blah, blah. Again, I like many of the ideas that these book authors promote,
    however, many of them seem incomplete (no mention of database design, GUI
    design, or web-based development) and are unworkable in practice (at least
    for me). Maybe each step of the development process truly needs its own methodology?
    For GUI development, Usage-Centered Design [Constantine & Lockwood] seems
    to be a good way to tackle user interface issues. For database design, I
    found the techniques and concepts described in the book Database Design [by
    Ryan K. Stephens and Ronald R. Plew] to be a very interesting read.

    I am starting to become convinced that the reason why so many small projects
    (1-3 developers) don't use any type of methodology other than iterative prototyping
    is that it is simply too difficult and time expensive to do it any other
    way. Many of the so called experts in our field will tell you that the client
    is the primary reason why code and fix development is so prevalent today
    (won't pay for analysis and design). On large projects where everyone plays
    a specific role this might be the case, however, on smaller projects, I think
    that this fact is simply irrelevant. For example, most of my "free time"
    is (and has to be) spent reading about programming related issues: software
    products, technologies, different programming/scripting languages, better
    testing, design, and coding techniques, etc. Who has the time to do/learn
    all the other stuff?

    I know that someone reading this post is probably thinking "wouldn't it be
    nice if all that was needed is a solid methodology (i.e. OO based with emphasis
    on use cases) in order to deliver incremental results to impatient customers".
    Obviously, I realize this is not the case. Even with a good project plan,
    a good analysis/design tool, a powerful visual programming language, followed
    by plenty of protoyping the odds that you will be able to deliver a project
    on time and within budget are not very good. Why is it that desktop, client/server,
    and web-based projects have the same reputation for budget overruns, unfulfilled
    functionality, etc. that remind me so unfondly of my mainframe days? Is it
    because the implementation details are so difficult and complex? Is because
    most project teams are skipping the early stages of analysis and design?
    Or could it be because we as an industry need to shift our attention back
    to the people and management issues, as is suggested by some recent textbooks
    and methodologies (i.e. Agile methodologies).

    Has anyone here came up their own "lightweight" methodology that they have
    been able to successfully use on many different types of software projects?
    If so, would you care to share a few words here on what you found works for
    you and what doesn't? Also, are there any web sites, newsgroups, etc. that
    talk about the problems of developing customized business applications on
    an independent basis?

  2. #2
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Does anyone really use a software development process?

    "Jim Jones" <jjones@hotmail.cm> wrote in message <news:3b16a5d8@news.devx.com>...

    > Again, I like many of the ideas that these book authors promote,
    > however, many of them seem incomplete (no mention of database design,
    > GUI design, or web-based development) [snippage]


    Yes, most gurus seem to gloss over databases, except to advocate using
    UPDATE SQL statements, which are quite happy to stomp all over each
    other with nobody the wiser. Sorry, I want timestamps, record locking,
    before/after snapshots, etc. Most times, my middle tiers can iron out
    the update conflicts and end up with a consistent database without ever
    bugging the users.

    > Has anyone here came up their own "lightweight" methodology that they have
    > been able to successfully use on many different types of software projects?
    > If so, would you care to share a few words here on what you found works for
    > you and what doesn't? Also, are there any web sites, newsgroups, etc. that
    > talk about the problems of developing customized business applications on
    > an independent basis?


    Add "refactoring" to the usual "code and fix", and you should be better
    off tomorrow, not a year from now after you've memorized the textbook.
    One people-ware trick I've used to head off feature-creep is to develop
    one feature at a time. List out the ones that have yet to be completed
    and ask the customer, if they could get only one from the list, which
    one would it be? It's an extreme form of the "A list/B list", but it
    seems to work. You must be comfortable with refactoring to do this, or
    you'll soon find yourself in a **** even Dante couldn't bring himself to
    imagine! Also, Feature 0 should be a way your components can determine
    if they're out of date, perhaps by automatically checking a [Versions]
    table?

    --
    Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  3. #3
    Ted Guest

    Re: Does anyone really use a software development process?


    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
    >"Jim Jones" <jjones@hotmail.cm> wrote in message <news:3b16a5d8@news.devx.com>...
    >
    >> Again, I like many of the ideas that these book authors promote,
    >> however, many of them seem incomplete (no mention of database design,
    >> GUI design, or web-based development) [snippage]

    >
    >Yes, most gurus seem to gloss over databases, except to advocate using
    >UPDATE SQL statements, which are quite happy to stomp all over each
    >other with nobody the wiser. Sorry, I want timestamps, record locking,
    >before/after snapshots, etc. Most times, my middle tiers can iron out
    >the update conflicts and end up with a consistent database without ever
    >bugging the users.
    >
    >> Has anyone here came up their own "lightweight" methodology that they

    have
    >> been able to successfully use on many different types of software projects?
    >> If so, would you care to share a few words here on what you found works

    for
    >> you and what doesn't? Also, are there any web sites, newsgroups, etc.

    that
    >> talk about the problems of developing customized business applications

    on
    >> an independent basis?

    >
    >Add "refactoring" to the usual "code and fix", and you should be better
    >off tomorrow, not a year from now after you've memorized the textbook.
    >One people-ware trick I've used to head off feature-creep is to develop
    >one feature at a time. List out the ones that have yet to be completed
    >and ask the customer, if they could get only one from the list, which
    >one would it be? It's an extreme form of the "A list/B list", but it
    >seems to work. You must be comfortable with refactoring to do this, or
    >you'll soon find yourself in a **** even Dante couldn't bring himself to
    >imagine! Also, Feature 0 should be a way your components can determine
    >if they're out of date, perhaps by automatically checking a [Versions]
    >table?
    >
    >--
    >Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
    >WARNING: I cannot be held responsible for the above They're coming

    to
    >because my cats have apparently learned to type. take me away,

    ha ha!
    >
    >


    I'm not sure what type of methodology you are referring to but the afore
    mentioned "Feature approach" is one of the main points of XP. If you pick
    up the XP book by Kent Beck or just check out his website I think you will
    be impressed. It is one of the newer methodologies to come out but I think
    if you give it a shot you may be swayed.


  4. #4
    JustInTime Guest

    Re: Does anyone really use a software development process?

    I don't have the "silver bullet", but I can give you my opinions, garnered
    after years of hardware/firmware development, which led into a larger career
    in software dev....

    A few years ago, my company merged with a consulting firm that also taught
    courses. They taught a course in MS-SDD, which is the Microsoft Software
    Development Discipline. Several of us went on the course. (were sent on it
    actually) I had read lots of books, been on courses for things like PMI-BOK,
    Rational, etc. All seemed like crap, and I had low expectations of his one
    too.

    Lo and behold . . . I was amazed.

    The SDD, rather than worry over the details of "this document should be
    written by this person by this time" is more of a common sense methodology.
    It covers off a lot if the things that people should think about, and
    suggest who should be thinking about them, but doesn't lay down a bunch of
    procedures. Mostly, it helps you collect your own thoughts, and express them
    to other involved in the project. Following it's guidelines can also help
    eliminate the dreaded "feature creep".

    I also have another point, which will likely be unpopular with most software
    dev types.

    Software development needs to become software engineering. I don't say this
    because I am an engineer. (I am a hardware engineer - not a computer
    engineer) More I mean that software development needs to follow some
    "engineering" principles:
    1. Design it
    2. Review the design
    3. Build it
    4. Inspect the build while ongoing
    5. Test it

    Everybody seems to accept that buggy software is the norm, but it doesn't
    need to be. Houses don't fall down and cars don't just break. Sure, the
    occasional ford pinto slips through the system, but people claim how air
    travel is safer than driving, but software has bugs way more often than cars
    crash. (On a per user per time basis)

    And don't talk about how people use software in ways it wasn't designed. How
    many times have you seen someone driving down the street with a sofa and a
    bed strapped to the top of their Honda Civic!

    If people treated the building of software like the building of a house,
    then they would be more careful, take longer, but end up with a much better
    product in the end. Yes, it would take longer, and yes it would cost more.
    But I think the end-result would be better for all. The users wouldn't have
    as much aggravation. Less upgrades/fixes would be needed. And software dev
    would have a better reputation.


    Just my two cents
    --


    TTFN
    Justin Bowler, B.A.Sc. P.Eng. | Don't waste your time going
    <jbowler@TRASH.sympatico.ca> | to just any old school...
    | Go to SKULEtm
    --- ERTW | <http://www.skule.ca>

    "Jim Jones" <jjones@hotmail.cm> wrote in message
    news:3b16a5d8@news.devx.com...
    >
    > Over the last few years, I work for staffing/consulting firms and have

    been
    > doing a lot of solo maintenance programming/support. As a result, my

    exposure
    > to the latest formal design and development processes is fairly limited.
    > I feel that I am good at solving problems and that I can write semi-decent
    > source code, but when it comes to the more formal aspects of what I do now
    > or will be expected to do on the next assignment (i.e. task estimation,

    requirements
    > gathering and documentation, the ability to take a small software project
    > from womb-to-tomb, etc.), I feel completely lost at times. Note: I am not
    > a newbie to software development, however, my career path has been

    somewhat
    > different from that of the stereotypical software developer in that I have
    > never had a "breaking in period" and have always been expected to "do it
    > all" so to speak.
    >
    > Up to this point, my approach or philosophy towards problem solving and

    software
    > development has always been to simply use whatever tools and techniques

    that
    > are available that will help do whatever it is that needs to done.

    Unfortunately,
    > I have come to realize that in the enviroment in which I find myself

    working
    > in (flying solo) that being able to solve problems and write source code
    > simply isn't good enough. While I have been trying to come up with my own
    > formal software development process, so far I haven't had much success.
    >
    > I have looked into RAD, iterative development, several of the agile

    (lightweight)
    > and heavy (RUP) methodologies and while I like certain aspects of each one
    > -- I don't think many of the ideas and techniques that they promote are

    well
    > suited to independent software development.
    >
    > It appears to me that many of the well respected industry developers (i.e.
    > book authors) have all developed their own methodologies. For example,

    Deborah
    > Kurata has her GUID methodology, Paul Reed created the Synergy process,

    blah,
    > blah, blah. Again, I like many of the ideas that these book authors

    promote,
    > however, many of them seem incomplete (no mention of database design, GUI
    > design, or web-based development) and are unworkable in practice (at least
    > for me). Maybe each step of the development process truly needs its own

    methodology?
    > For GUI development, Usage-Centered Design [Constantine & Lockwood] seems
    > to be a good way to tackle user interface issues. For database design, I
    > found the techniques and concepts described in the book Database Design

    [by
    > Ryan K. Stephens and Ronald R. Plew] to be a very interesting read.
    >
    > I am starting to become convinced that the reason why so many small

    projects
    > (1-3 developers) don't use any type of methodology other than iterative

    prototyping
    > is that it is simply too difficult and time expensive to do it any other
    > way. Many of the so called experts in our field will tell you that the

    client
    > is the primary reason why code and fix development is so prevalent today
    > (won't pay for analysis and design). On large projects where everyone

    plays
    > a specific role this might be the case, however, on smaller projects, I

    think
    > that this fact is simply irrelevant. For example, most of my "free time"
    > is (and has to be) spent reading about programming related issues:

    software
    > products, technologies, different programming/scripting languages, better
    > testing, design, and coding techniques, etc. Who has the time to do/learn
    > all the other stuff?
    >
    > I know that someone reading this post is probably thinking "wouldn't it be
    > nice if all that was needed is a solid methodology (i.e. OO based with

    emphasis
    > on use cases) in order to deliver incremental results to impatient

    customers".
    > Obviously, I realize this is not the case. Even with a good project plan,
    > a good analysis/design tool, a powerful visual programming language,

    followed
    > by plenty of protoyping the odds that you will be able to deliver a

    project
    > on time and within budget are not very good. Why is it that desktop,

    client/server,
    > and web-based projects have the same reputation for budget overruns,

    unfulfilled
    > functionality, etc. that remind me so unfondly of my mainframe days? Is it
    > because the implementation details are so difficult and complex? Is

    because
    > most project teams are skipping the early stages of analysis and design?
    > Or could it be because we as an industry need to shift our attention back
    > to the people and management issues, as is suggested by some recent

    textbooks
    > and methodologies (i.e. Agile methodologies).
    >
    > Has anyone here came up their own "lightweight" methodology that they have
    > been able to successfully use on many different types of software

    projects?
    > If so, would you care to share a few words here on what you found works

    for
    > you and what doesn't? Also, are there any web sites, newsgroups, etc.

    that
    > talk about the problems of developing customized business applications on
    > an independent basis?




  5. #5
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Does anyone really use a software development process?

    "JustInTime" <jbowler@THETRASH.sympatico.ca> wrote in message <news:3b1f0321@news.devx.com>...

    > If people treated the building of software like the building of a house,
    > then they would be more careful, take longer, but end up with a much better
    > product in the end. Yes, it would take longer, and yes it would cost more.
    > But I think the end-result would be better for all. The users wouldn't have
    > as much aggravation. Less upgrades/fixes would be needed. And software dev
    > would have a better reputation.


    How do we get there from here, though? As project estimates make their
    way up the management food chain, the time and resource estimates get
    chopped by 20% at each level, even by former project managers! Meanwhile,
    we continue to assume that if one developer can deliver a program in nine
    months, nine can deliver it in one month or even less! After all, a sole
    developer might slack off at only 80 hours/week, while we can whip the
    team along at 160 hours/week for two weeks... Also, unlike exploding cars,
    crashing crapps typically aren't headlined on CNN. Just download the new
    Service Pack!

    --
    Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center