piclist 2009\02\06\105256a >
Thread: Agile programming (was Re: [P|C] Banksel)
face picon face BY : Rolf email (remove spam text)

Gerhard Fiedler wrote:
{Quote hidden}

[ Whole bunch of fascinating stuff snipped..... ]

> Gerhard

Oh, holy cow batman. Thanks Gerhard. Your post inspired me to read that
website. I could hardly believe that all those things you quoted were
the Agile 'mantra'. They sound like things written by poor advertising

So, some quick responses to Agile development now that I have spent (a
little) time reading up on it.... in response to the 13 "Best practices
of AMDD"

1. Active Stakeholder Participation  - Our company has many clients
(hundreds) that all purchase and use the same software.... now what? Our
development happens in 8 countries and our clients are in many language
regions (from Colombia to Japan). Again, now what? "Active Stakeholder
Participation" using "Inclusive tools and techniques". OK, I go to
client meetings on occasion, and we have whiteboards, but I don't think
I can take a ball of string to my next meeting at Citibank. Then again,
we have whole teams of people who communicate regularly with clients and
determine the 'functionality voids' that become requirements for our
systems. They get this from discussions and on-site needs assessments
with the clients, and prioritize things, and we deliver at some point.
This process is all about prioritization and compromize.

2. Architecture Envisioning - they admit that this is really what I
would call 'good progect design'... choose the right
environments/people/teams up front because you really don;t want to
re-write everything later when your client uses UNIX instead of Windows,
or some other problem. This is where my 'Wise/Experienced' Manager comes
in - they instinctively know how a project will have to unfold in order
to be successful. This setup phase is critical for the success of the

3. Document Late - I am surprised that Wiki pages do not appear in the
things I read. I find them invaluable for maintaining a close
relationship between the specifications and compromises that inevitably
happen during the development of the code. The formal documentation
people can then use the wiki's to keep their work in line with reality.
It also allows the documentation process to be started before even the
programming is, and then the documentation can be comprehensive about
the requirements, can be re-active to known issues, and can even be
completed at pretty much the same time as the program itself. Why
document Late when you can get better delivery by documentin
concurrently and keep the documentation up to date with useful tools
like e-mail and wiki's. A huge tool for our documentation guys is also
the bug-tracking software we have, because it is intricately linked with
a lot of things and all issues can be documented and the process is
comprehensive. The bug-tracking software has specific components
designed to be used by documentation people so that we (the developers)
can keep the documentation up to date with changing features/known
issues. Documentation is a process, not a product. Well, that's how I
feel anyway. If you leave it all to the last minute you get incomplete
documentation. Sure, it is hard to keep documentation current with the
code, but, they don't pay me money to slack up on the important stuff.
Documentation/comments/bug-tracking and prioritization are at least as
important as the program itself. Programming only means you do a 1/4 of
a job.

4. Executable Specification - we have another department of "Financial
Engineers". They determine how to model financial concepts, and part of
that process is the development of meaningful test data so that we can
develop with some form of certainty that we will hit the mark with the
final product. So, sure, I agree that "Executable Tests" are important.
We also have another department that takes the test data and warps and
breaks it in such a way that we ensure that our code can process broken
data and responds appropriately, so we also have an executable
ex-specification too.

5. Iteration Modelling - an Agile iteration is a 'short time' (couple of
weeks or so). This tells me that the developer should know where they
are going to aim for in the next 'iteration' - what they want to get
done. Sure, anything else is wrong, really. All this says is that if you
want to get to place X at the end of an iteration, then you have to know
where X is, and how to get there... I guess the alternate is to not do
iteration modelling, and just programm to no 'model' and maybe you will
get somewhere useful. I must be missing something else because this
concept appears so common-sensical.... Perhaps the agile 'Iteration' is
not what I understand, but, if I had to spend some time implementing a
financial feature, I would first determine what my data requirements
were, where that data was to be stored, how I was going to process it
(like in the database, or a seperate program), and how I was going to
present the results to the next in line process/report, etc. Break that
down in to 'iterations', and each can be modeled in more detail.

6. Just Barely Good Enough Artifacts - Do only as much as needed for the
situation at hand - I'll comment on this one with the next one....

7. Model a bit ahead - this is a contradiction of 6. I thought that you
should only do as much as needed for the situation at hand...? Now we
need to model/plan/think ahead 'to reduce overall risk'.

8. Model storming - "model on a just-in-time basis" ... "to think
through a design issue". Again, contradictory, do I model a bit ahead,
or do I model only when needed?

9. Multiple models - no idea if this makes sense. The only way it makes
sense to me in the context it is written is if the type of "Model" that
practice 9 refers to is different to the type of model that 5, 6, 7, and
8 refer to.

10. Prioritized Requirements - according to 'stakeholder' interests -
this makes no sense... The stakeholder wants results. Results are the
consequence of a process, and have a logical progression where there are
dependencies (perhaps co-dependencies) that need to be accomplished
before a result is achieved. In order for this to make sense, you have
to break the 'final product' down in to sensible sub-products that make
sense to the client, and then focus on the delivery of a logical subset
of the functionality. This is called "compromizing" and is common to
many projects I do. Not all functionality is delivered with the first
version, but will be expanded/completed later. This is part of a client
negotiation process, but, after that is done, then the order of
development is not determined by the client, but by the logical
progression required to accomplish the reduced goal (which the added
complexity of developing with the full product in mind so that when the
remainder of the product is implemented it needs as little re-work of
the initial deliverable as possible.

11. Requirements Envisioning - this is just a souped up way of saying
"know what your customer wants". I notice that it explicitly says "at
the beginning of an Agile project". So much for welcomming requirement
changes at the end.....

12. Single Source Information - keep information in one place and one
place only. Get real. I have a bridge to sell anyone who believes this
can be done. Data is unprocessed information. Information is data that
is taken in a context. The context of the data is as important as the
data itself. What the programmer considers to be information is
different to what the end used considers to be information. The same
data has to be represented different ways to make the data become
information for the different parties. Saying that information should be
kept in one place is diminishing the value of data. Data has to be
expressed in different ways to accomplish different goals.

13. Test Driven Design - No problem with this. I use the technique often
- in context (both big and small scale). But, remember that the tests
need validation too.

All in all, I have to agree with my colleagues at work. Agile is a
non-starter for our company. It seems to be most appropriate for
software projects with clients of a certain nature, and not the system I
have at work. Given that I take issue with most of the 13 best practices
of ADMM, I guess I misunderstand things.

My impression of the 'best practices' is that it is a collection of
compressed 'sound bites' that have lost the weight of the argument in
the compression.

Anyways, I like number 6 the most: "Just Barely Good Enough Artifacts".
Sounds like it can be applied to anything, including agile development

... I hereby claim to be an Agile programmer because my "programming
methodology" is Just Barely Good Enough! ;-)  ;-)

Finally, the way the whole site is written is not like a 'must-do'
thing. It is more a case of 'zen buddism' and 'third person' stuff. I
have a mental image of Yoda that is in my mind when I read the page.
"The Agility .. you must embrace ... or a Jedi you are not!" "A
disturbance in Agility, your document is too early".

<498C5CAB.7020602@rogers.com> 7bit

In reply to: <84xmmdvgfuau$.dlg@connectionbrazil.com>
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Agile programming (was Re: [P|C] Banksel)

month overview.

new search...