«

Arne Vajhøj wrote:

> 1) "Good techniques if it fits, but who runs projects that way?"
> 2) "just the pictures, not the process"
>
> I can not see any consistency.

UML is a good technique for the substantial pre-coding descriptions
produced during classic waterfall. But who still gets to use waterfall
?

It also has some use for Scrum, as Scrum is largely "waterfall
techniques made usable for modern project cycles".

UML is the most useful part of RUP. I have no use for RUP in total. I
have no use for Rational's bug-ridden toolset. With just UML and a
whiteboard though, I can design and communicate it to others..

Danno wrote:
> I am just curious what people here use. Consider this a "get to know
> you" post.

I think the prevailing thought on process is "just write the damn code"
as Chris put it But today its usually more of an iterative approach.
This is especially important in bigger projects or where the details of
the functionality is sketchy. That's why you iteratively code your way
into the details of the problem. There are many forms of iterative
processes, rup, agile/xp, select perspective and a host of others. You
should not get stuck in a specific process, what you need to do is read
a bit about the different ideas behind the processes and apply the ideas
as you see fit to your project or company. There is no single or line of
processes that contains the whole set of solutions that is best for your
project. In any case, a project is as much about what the participants
are comfortable with. Half the success of a project/company is a
satisfied team of quality participants. Forcing team members to use a
specific process because it fits with an idea or argument the management
has only spells disaster in the long run.

tom

Tom Forsmo wrote:

> I think the prevailing thought on process is "just write the damn code"
> as Chris put it

Not here. 8-( I've spent 20 years fighting against this approach.

I have no shortage of code. I've got 2000 source files of it in front
of me, and most of it's ugly crap written by unskilled peons. The last
thing I need is more people "just writing the damn stuff", I'd like
some that _worked_. Maybe some code with some _thought_ behind it, not
the "Mavis Beacon Teaches Java" typing-exercises I'm seeing pouring out
of the bucket shops at the moment.

Andy Dingley wrote:
> Tom Forsmo wrote:
>
>> I think the prevailing thought on process is "just write the damn code"
>> as Chris put it
>
> Not here. 8-( I've spent 20 years fighting against this approach.
>
> I have no shortage of code. I've got 2000 source files of it in front
> of me, and most of it's ugly crap written by unskilled peons. The last
> thing I need is more people "just writing the damn stuff", I'd like
> some that _worked_. Maybe some code with some _thought_ behind it, not
> the "Mavis Beacon Teaches Java" typing-exercises I'm seeing pouring out
> of the bucket shops at the moment.
>
Right on.

Decompose the requirements, produce a good modular design with built in
scalability and ways round bottlenecks (e.g. some parts of the design
may need configurable parallelization). Specify to the module level and,
while you're doing this design in performance measurement, system-level
tracing/debugging and restart & recovery. All of these WILL be used
unless you're designing a simple stand-alone program.

Resist all attempts to start coding until this point has been reached or
you'll waste endless time during integration testing, when you suddenly
find that the system can't be started or stopped cleanly and that
modules developed by different groups don't talk to each other.

Then and only then code, preferably using some form of top-down
incremental development method. AFAICT all the fashionable extremely
agile team scrums are merely elaborations of this. IMHO unit testing and
regression testing are non-optional parts of module development.

Integration testing can start as soon as the various modules can
demonstrate basic functions in unit testing and the problems that
integration testing find can be fed back into module development.

Finally, system test against test cases developed directly from the
original requirements. This should be reasonably short and sweet if all
the above was done adequately but will stretch into next century,
finding endlessly multiplying bugs if the previous stages were skimped.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

Andy Dingley wrote:

> I have no shortage of code. I've got 2000 source files of it in front
> of me, and most of it's ugly crap written by unskilled peons. The last
> thing I need is more people "just writing the damn stuff", I'd like
> some that _worked_. Maybe some code with some _thought_ behind it, not
> the "Mavis Beacon Teaches Java" typing-exercises I'm seeing pouring out
> of the bucket shops at the moment.

It's hard to find a process that will work when people who don't know
how to code are doing a lot of the coding. Maybe that's why
document-centric approaches work better for some organizations. It
gives all the bad coders something to do besides breaking the code.

On Tue, 17 Oct 2006 00:27:39 +0100, Andy Dingley <>
wrote:

> Soon I hope to have weaned some of the other teams onto using source
> code control 8-(
>

Please tell me that's a joke...

Dan.

--
Daniel Dyer
http://www.uncommons.org

Andy Dingley wrote:
> Tom Forsmo wrote:
>
>> I think the prevailing thought on process is "just write the damn code"
>> as Chris put it
>
> Not here. 8-( I've spent 20 years fighting against this approach.
>
> I have no shortage of code. I've got 2000 source files of it in front
> of me, and most of it's ugly crap written by unskilled peons. The last
> thing I need is more people "just writing the damn stuff",

Well we all know that, what was is?, "1000 monkies hitting a typewriter
will eventually write Shakespeare" is not realistic, its a statistical
possibility, and that's it. Same goes with coding, you have to have able
and earnest programmers to create good code. If you don't, then of
course they are going to write crap, so either you have to teach them or
get read of them. I have worked in companies where they only hire expert
programmers. The type of programmer that writes larger and
semi-complicated code in a couple of days, while others might use 2
weeks, and the code is almost flawless. I know it sounds like an
exaggeration, but I witnessed it myself in the beginning and it left me
speechless. And from that I learned what good programming is and allows
me to do, if done correctly.

Btw, I forgot a couple of points when writing my previous post, so I
will make the additions now.

Just writing the code in it self is not good enough. You have to have
some structure to the procedure of writing the code. There should be an
agreement on what needs to be done and how to do it. In the above
example, there was usually an task/architecture meeting between the
programmer, the project leader and a senior programmer managing the code
base for that part of the system. The point of the meeting was to have a
common understanding of what to do, how to do it and how to use the code
base to achieve it. If there were any details that needed to be
recorded, we used bugzilla. Bugzilla was the overall archive of all
things coded, and every piece of code checked in to subversion had to
correspond to a bugzilla bug and had to be relevant. To ensure this,
senior programmers had control over the master branch, the senior
performed a code review and the final checkin (even for each other). If
there were any questions during programming, a senior was consulted. So
the senior programmers acted as the guardians of the code base and hence
the code was kept to premium quality. There where other parts such as
testing procedures and bug verification procedures, but that are details
I wont go into here now.

This kept the development process light, capable of supporting change
and above all helped us write excellent and functioning code. This made
programmers and management happy because everybody could focus on their
main tasks instead of long meetings and endless specification
discussions. Tasks were divided into smaller parts so it could be done
by one or two programmers and so that no single task took too long time
to complete. Everything was checked by several people by way of small
meetings, or coffebreak discussions, without having to resort to a paper
mill production. By working iteratively and hands on from the start we
learned to understand things intimately from the start and could avoid
problems and pitfalls before they even existed.

As another point, later I worked on a project where the management tried
to enforce a rigid structure and force us to use xp, scrum etc
indiscriminately. The project soon fell apart, in dissent. I, and
shortly after, another, walked away from the company. They did not
consider the team or the individuals and how they work best together.

tom

Tom Forsmo wrote:

> a senior programmer

What's a "senior programmer" ?

Someone who has been there the longest and has seniority?
Someone who has been there for some years, seen only this project,
ignored the rest of the world's progress, and is probably responsible
for much of what's wrong with the current state of things?

Hmmm.......

Danno wrote:
> Arne Vajhøj wrote:
>> Andy Dingley wrote:
>>> Arne Vajhøj wrote:
>>>> I assume you mean UP not UML.
>>> No, I meant UML - just the pictures, not the process.
>> 1) "Good techniques if it fits, but who runs projects that way?"
>> 2) "just the pictures, not the process"
>>
>> I can not see any consistency.
>
> Seems fine to me. He is just asking who runs their projects by using
> UML anyway? In most agile practices you build into the patterns you
> need and you don't define them before hand.

No. Has asked for processes. You brought up UML which is not
a process but a modeling language.

Arne

kevin cline wrote:
> It's hard to find a process that will work when people who don't know
> how to code are doing a lot of the coding.

So true, so true.

> Maybe that's why
> document-centric approaches work better for some organizations. It
> gives all the bad coders something to do besides breaking the code.



Arne