Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re: Planning your software before writing

by KM (Priest)
on Jan 08, 2001 at 19:41 UTC ( [id://50493]=note: print w/replies, xml ) Need Help??

in reply to Planning your software before writing

I have used Visio before, but tend to go back to the analog whiteboard. I have often thought of a 'correct' way to plan and map software (at least Perl-centric software). I have worked a few places in my time, and find that a 'correct' way one place wouldn't work somewhere else. It all depends on the people on the team, company policy, etc... In general, however, I think there are a few things that always help, and are staples for planning software.

  • Clear 1000 foot view of software. It will do X, and be used by Y.
  • Map of any integrations. Interfacing with existing database? Need new database? Need new tables? Interfacing with software? Is there an API? etc...
  • General bubble chart (flow-chart without real flow) of 500 foot view. Can this be modular? Can sub-teams work on various parts (ie. Admin section, backend, front end, UI, etc...).
  • SPECS!!! SPECS!! SPECS!! The specs should have specifics and details of how things will work. These should be worked on by management AND development.
  • Final specs should include list of technologies being used (XML,Perl, Apache, Oracle, etc...) so they can be installed.
  • Now, have fun on the whiteboards. I see things work well when sub-teams create DETAILED flows of their bits, then explain their bits to other sub-teams. This helps you see how the bits will touch and mesh and allow for people to know what API's to make sure they have for other bits. Then, revise flows and details as needed.
  • Develop! Changes will be made, things will be added/removed.. there is no permanence in software design.

There is a lot in between (I could probably do a book on dos and do-nots of real-world software design), but those are some highlights I have seen work well. Generally I don't like to use any flowchart software (unless someone else will maintain the flowcharts) because whiteboards are better (if you are luckly, you have a whiteboard that prints). I love walking into a room and seeing all the whiteboards marked up with the flow of a big piece of software!


  • Comment on Re: Planning your software before writing

Replies are listed 'Best First'.
Re: Re: Planning your software before writing
by belize (Deacon) on Jan 08, 2001 at 20:15 UTC
    I see your point. Overview to specifics and if the specifics can be broken into teams the better.

    I am coming from a little smaller company (9 employees) that are struggling to fill the niche of customers that have around 10-15k to spend instead of the 800k or more for the big boys.

    I have often wondered whether it is better to built something form scratch or to look for something that has already been done and modify it. The first way takes more time, but gives you exactly what you want. The other takes less time, but often does not give you what you want.

    Programming always seems to be a trade off between time, money,and functionality (maybe we should add reliability?).

      The other takes less time, but often does not give you what you want.

      Well, that depends on what you find to build on. If you find something (or some things) that were well designed to build off of, it can save you time. If you download crap to use, then you have crap to work with. I once had to do a calendaring system.. I found a Perl one on Sourceforge (don't recall the name right now) and it was decently written, and had much of the functionality I needed, and was easily expandable (I added tons of things, and now use my version for my own personal use). So, in that case it saved time. Before finding that one I looked at another, which was crap, and I saw a long hard road ahead. I didn't start from scratch because of my task load, and I happened to find something very usable.

      Programming always seems to be a trade off between time, money,and functionality (maybe we should add reliability?).

      I say, let the managers worry about money (and maybe the time) and the programmers worry about functionality (reliability, readability, scalability, and all other bilities). If you happen to have a boss who isn't afraid to tell a customer 'it will take an extra two weeks, because we want to make sure it is a good piece of software now, rather than fix things later', all the better. Crap gets created when you have someone saying 'Well, just make it work they want it on Friday'. Personally, I think a programmer should say 'No, it will be done when it is right', but some value the paycheck to much :)

      Anyways, when you have the 1000 foot view, it is a good time to research what is available that can be a base to work from, IMO.


Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (1)
As of 2024-06-17 01:22 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.