Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: My number 1 tip for developers.

by Anonymous Monk
on Sep 12, 2003 at 06:43 UTC ( #290940=note: print w/ replies, xml ) Need Help??


in reply to My number 1 tip for developers.

Start1 by typing as much as code as you know will work.
Bad idea. Follow the basic software engineering steps
  • spec - obtain a spec
  • analysis - understand the problem/spec ... maybe prototype (this is where you throw stuff away)
  • design - pseudocode
  • implement - write it
  • test and verify - you can do this while implementing
  • maintain and update
Your way sounds like it would take twice as long as anyting else.


Comment on Re: My number 1 tip for developers.
Re: Re: My number 1 tip for developers.
by htoug (Deacon) on Sep 12, 2003 at 07:14 UTC
    That was the preferred way of doing things when I started - way back in the early '70ies.

    Things have progressed since then!

    The recommended way is now a variant of Test early, test often mixed with Iterate - either XP, Agile or perhaps some form of RUP (for the BSDM fans) or whatever the current name is.

    Nowadays you prototype, testing as you go along, releasing incrementally and refactoring when needed, all in an iterative way. All this requires a strong test-suite, which is buld preferebly before development. Testing is a lifelong process, and the testsuite keeps growing - often it is larger than the application - but it keeps everyone happy, as we all know that the system is working as expected.

      That's why I say test and verify - you can do this while implementing .

      Basically I agree with this other AM at Re: Re: Re: My number 1 tip for developers..

      You and BrowserUk both seem to have a different understanding of the steps. Perhaps I should have emphasized basic in the basic software engineering steps. There are no subcategories. There are no metrics.

      BrowserUk says The whole point of the tip is the idea that you learn to recognise (as early as possible) when you are wasting time trying to 'get something to go', and that's a good tip if you get writers coders block. I suppose my only uneasiness with BrowserUks original node is that he first tips on the mechanics of banging a keyboard, when spec/analysis and then design is what you always need to start with.

Re: Re: My number 1 tip for developers.
by BrowserUk (Pope) on Sep 12, 2003 at 15:28 UTC

    You've just describe (in breif) the waterfall method. As beloved of CompSci faculties and IT departments from the late 60's on. It Was then, Is now, and ever shall be the worst way to develop software ever devised (IM(NS)HO:).

    The biggest problem is that the main criteria that it satisfies is based upon flawed metrics--kLOCs, function points etc. Project progress is measured in terms of how much code has been written. That's equivalent to measuring one's progress on a journey in terms of how far one has traveled, instead of how much closer you are to you destination.

    You can travel a very long way, and do so very fast, but unless you have regular and mandatory checks to ensure that you are travelling in the right direction, measurements of how far you have travelled are entirely bogus. But even simple checks of progress are not enough. It is entirely possible to complete a journey from A to B by spiralling around A in an ever increasing arc (Archemedian Arc?) until you arrive at B. If you take your progress measurements at inopportune points, it may seem like your making steady progress, and unless you have an overview, you won't see the flaw.

    I was required to use this methodology,and still have a plastic laminated reference card outlining the "10 stages of The Project Development LifeCycle" which breaks these 10 stages into 102 substages. I keep it on my wall as a reminder of the "Bad Ol'Days", the mid to late '80's in my case.

    I worked on a project that had 1000 developers working at 8 sites across 2 conglomorates in 6 countries. Millions of lines of code developed "To a spec", and then saw the huge mess when they tried to integration test the results.

    No thanks:)

    I'll stick to those bits of the half-a-dozen-or-so methodologies I've seen become the latest fad, and then fade, that made the transition from a rule written on paper, to something I personally found useful enough that I continued the practice even after I no longer had to do it.

    As for the term "software engineering". In my opinion, that is an oxymoron. See Re: How do you view programming for an explanation of why.

    Your way sounds like it would take twice as long as anyting else.

    The whole point of the tip is the idea that you learn to recognise (as early as possible) when you are wasting time trying to 'get something to go', and start again. It's my personal experience that doing anything the second time is easier than the first. I've also found that trying to fix-up a first attempt usually takes longer than starting from scratch. So the purpose of only typing as much in each go as you know will work, and then testing that it does, is designed to minimise the amount of code that you need to revisit at any stage.

    Writing code is easy, it's finding the bugs that is hard! So don't try and find them. Throw the bugs away and write again. IME, this gets you to the end of the journey much faster, because you spend much less time retracing your steps.

    In the end, this was only my tip, offered on the basis that some might grasp the logic and find it helped them, but like all tips and advice, it's entirely ignorable:)


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
    If I understand your problem, I can solve it! Of course, the same can be said for you.

      I learned the Classic Development Cycle quite differently from most people (it seems). My high school Comp Sci instructor (1979) presented this basic software development flow and then immediately used it to introduce concepts of iteration, recursion, and feedback (on the model itself). I never felt that the Classic Development Cycle approach was flawed, just most people's interpretation and implementation of it (as a one-way monolithic process). To my mind, modern methodologies like XP seem like natural extensions or revisions of the classic model (as I learned it), not radical departures.

        Actually, I agree with you.

        One of the few real benefits of accumulating age, is that you begin to see that most if not all of the details of the 'new methodologies' that have a habit of springing up every 10 years or so are simply re-inventions, re-discoveries, re-interpretations or re-implementations of stuff that was known and formalised (in that laborious and dry-gulch way so beloved of the era) by the early pioneers in the field. The differences are mainly in the terminology used, the categoricality (sp? Is that a word?) of the dos and don'ts, and the formality and seperation between the stages.

        In the good ol' bad ol' days, when (and by whom) the stages of the processes where performed was much more clearly defined and seperated. The main change (IMO) between the Waterfall method and XP, is that XP tends to encourage the iteration/recursion to happen much earlier and more frequently in the cycle than the older methods. It also encourages the coder to do this himself, and for himself.

        In many ways, this mirrors changes in other industries, often termed "removal of demarkation". In the car industries of the '70s and '80s, production was done by production workers, maintainance by maintainance workers, testing by testers etc. etc. And so it was with software. Coders coded, testers tested, analysts analysed and designers designed.

        In the early '90s (if memory serves), Volvo scrapped the production line system and moved to "production teams". Basically, they organised their (no longer demarkated) workers into teams. Each car was built by a single team. They did everything from production to testing to re-working. The effect was to make them jointly responsible for the overall output of their team. Each person was trained to do every function and they did what ever was required to get the job done. Not only did this vastly improve the quality of their output and reduce the amount of remedial work required, it also induced group reliance and responsibility and resulted in a higher sense of satisfaction, lower staff turnover and sickness.

        I see XP in a similar light. It doesn't remove or add to the individual stages as laid out all those years ago in the CDC. It simply interleaves them, removes the levels of stratification that existed, and puts the onus upon the individual to produce and maintain a quality product rather than volume. The overall result should amount to the same thing, but in practice, the XP model tends to iterate or recurse earlier and less deeply, so the problem of "blowing the stack"1 tends not to occur.

        1In perl terms, this is the dreaded "Deep recursion" followed by the worse "Out of memory". Many projects using the Waterfall model fell foul of 'blowing the stack', which meant that they ran out of support and then cash (which amounts to the same thing). It's not that they wouldn't have arrived at a working solution, its just that they got so far into the projects before they discovered the flaws, that they had a long way to backstep before they could move forward again. In the meantime, long development cycles meant that large sums of money went in without anything much coming out. Hence it became a regular practice (here in the UK I know for sure, but I think other places also) for entire software projects to be scrapped because the cash was cut off before the project could reach a stage of showing its worth.

        The major change (and benefit) of the modern re-workings of the early development cycles is that the aim is to have something demonstrable as early as possible. Once you can demonstrate that progress is being made, it is much easier to carry good will (and the cash that comes with it) forward.

        In development terms this translates to finding and remedying your bugs as soon as possible which results in smaller steps back individually and much less time moving backwards overall.

        My tip encapsulates this idea, and was meant to encourage those starting out to not be afraid of moving backwards (a little). Every project, large or small, will always have to re-trace and re-group from time to time. Minimising the distance re-traced is the key.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        If I understand your problem, I can solve it! Of course, the same can be said for you.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://290940]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (9)
As of 2014-09-30 18:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (381 votes), past polls