Exactly - i still stick to the belief that a small team of highly skilled
programmers will code quicker from a single page spec than a thousand low
quality coders using a high detail spec. Many an institution disagrees, or
rather has been stung by smaller teams giving promises that they can then
Alleluia! Brother!
Jerry Banker
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen
Sent: Wednesday, October 14, 2009 5:00 AM
To: 'U2 Users List'
Subject: Re: [U2] Unibasic: Sample program - to extract
Should those thousand low quality coders quit their jobs and line up
at the local soup kitchen?
If it is true that the world needs more computer programs... it follows
that the world needs more programmers,
not less.
-Original Message-
From: Symeon Breen
Sent: Wednesday, October 14,
As a programmer who has had to maintain and enhance systems that were
written apparently based on a one-page spec that everyone on the team
understood, when the team members are no longer there, and the documentation
was all between their ears (and left with them), I am a big believer in
John, I agree that listening to the super users is critical. However,
writing a detailed spec will give those super users the ability to review
the spec, add their 'second thoughts' (and the wow, this is really cool -
could it also do this? ideas before the files are designed and the code
Susan,
As a contractor, I agree completely about getting a sign off on specs. I have
been in that boat too. The same is true if you have super-users who may not
really be that super.
In my current position (on-staff code-monkey), the level of trust is very high
between the U2 team and the
In message 02fb01ca4c38$ab3ad6c0$01b084...@com, Symeon Breen
syme...@gmail.com writes
Actually for many it is mass produced. Specification is being done to the
absolute minutia, for example in the Unified Rational process, when
generating use cases these get transmitted down to the architectural
I'm with Susan on this. My job as a consultant is to help
clients define what they want so that anyone can code it. My job
as a programmer is to implement the spec that was defined. These
are two separate skills. Without specs the programmer codes what
he/she thinks is required, leaving the
Documenting the program or application is always a good idea, it also helps
if changes to the programs are documented, but having to write the specs to
the smallest minutia is overkill. Unless, you are writing the specs for
someone else that doesn't know your business or the next person in line
John's world is similar to my world here. When I realized that I would
be the only person reading the specs, I stopped writing to myself. At
the risk of no longer being a professional dinosaur, I learned that some
people call it agile.
Check out... Eckhart Tolle's book The Power of Now.
--B
Yes, some people also call it scrum.
Brenda L Price
UniVerse Programmer
Rapid Response Team
Market America, Inc.
Greensboro, NC
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of Brutzman, Bill
Sent: Wednesday,
Ah, it must be lovely to know that you will live forever and will never
become ill or incapable of working... Eventually, if the company does not
go out of business, or their business needs change so much that all your
code is obsolete, somebody else will have to figure out how the system
Well, when our company gets this fully implemented. You can count over
250 Highlander's Immortals on the list!
Seriously, check out agile and scrum, it is interesting.
Brenda L Price
UniVerse Programmer
Rapid Response Team
Market America, Inc.
Greensboro, NC
-Original Message-
From:
My experience is exactly the opposite. Well written, simple code that
approaches its function in straight-forward manner is worth 1000 lbs of
specs and documentation. I never, ever approach a maintenance project
under the assumption that the documentation from back when has any
relevance to
Agreed on the simple, top-down code with adequate documentation built in. FROM
this kind of code, specs can be reverse-engineered. Then those specs can be
presented to those utilizing the product to make sure THOSE specs fit the task
at hand.
And some advise I took from 'The Mob':
I don't
On the other hand some of us end up spending senseless days
re-engineering a product every time management changes it's mind what
the product should do. It's a good thing I get paid for doing what the
boss says rather than getting paid by completed projects.
My boss actually brags about our
I agree, agile and scrum are the way to go
However, this is not just a term for no specifications and an open ended
project.
This methodology requires a commitment of time and effort by all
parties, most importantly a dedicated person from the business tied to
the project who has a stake in
Mine did too - he came from the Cobol world and didn't think much of
multivalue systems until he asked me to do a project, signed off on my spec,
and 2 days later had a completed, documentated, ready to fly system up and
running. He was stunned - he thought it was a 6 month project (and he
My experience in this is as a software vendor - it can be very dangerous to
engage with a customer in an agile development - As a vendor we supply our
packaged product with a certain amount of modification. It is very important
that such modifications are ring fenced, costed and planned before the
Two keys to making agile safe are [1] OSGI config management and [2]
software test. Of course, customers want everything done yesterday.
--Bill
-Original Message-
From: Symeon Breen
Sent: Wednesday, October 14, 2009 4:27 PM
My experience in this is as a software vendor - it can be
Possibly, and while it probably works better with internal teams, I
think it goes back to what I was saying about it being a partnership
approach. Most vendor/customer relationships are not partner at all,
they may say it is a partnership, but the nature of the beast dictates
otherwise. So if a
Brenda, I did check it out, and it is interesting, but I still wonder if 3
years later, when the business requirements change, if anyone from the
original team will a) be there, and b) remember all the intricacies of the
design decisions made, and c) be part of the new team to modify the
Agile and Scrum (basically agile 30 days sprint cycles) doesn't mean the system
does not get documented. It just means a more iterative process with decisions
being made later in the cycle. Welcoming the change request does not mean
that the change doesn't get documented. It means the documents
Robert, there you have my favorite phrase If maintained properly - no
matter what development practices, the key is to maintain the documentation
so that the next change request can be reviewed against an accurate
understanding of the system (particularly in light of the diverse tools now
I think it also depends on a lot on the toolset you are using. This
approach, if you are writing code in pure pick basic, with minimal
dictionaries for the files you are using could be suicidal, yet with the
right tools and mindset, this can be a VERY productive way of working.
In this regard, I
I could not put it more eloquently Ross.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of Ross Ferris
Sent: Thursday, 15 October 2009 1:00 p.m.
To: U2 Users List
Subject: Re: [U2] Unibasic: Sample Program
I
26 matches
Mail list logo
