On Wednesday, November 23, 2011 at 10:57 AM, Stéphane Ducasse wrote:

Number 1 question I always ask but is sort of implicit in the other questions is,

why was this change made?

which impacts on, is it still valid and is this change impacted by a change that happened in another brach of software.

I find the question How Large is it interesting because it can be easily
enhanced to complexity metrics. Two simple ones are #loc and #sends (you
don't need to compile a method to count the number of message sends it
contains). If the change represents a Class definition you could measure
the number of instance variables. Changes that remove classes or methods
would subtract their complexity from the total. There are more metrics easy
to calculate. The point is that with these considerations you could ask how
much complexity the change set adds to/removes from the system.

leandro caniglia ph.d. | chief technologist | caesar* systems | see
clearly. decide smarter.*

lcaniglia@caesarsystems.com | t: +1.281.598.8810 +1.281.617.2972
+54.11.4389.0126 | petrovr.blogspot.com | www.caesarsystems.com

This message and any attached documents contain information from Caesar
Systems LLC that may be confidential/trade secret and/or privileged.  If
you are not the intended recipient, you may not read, copy, distribute or
use this information.  If you have received this transmission in error,
please notify the sender immediately by telephone or by reply e-mail and
then delete this message.

On Wed, Nov 23, 2011 at 12:57 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:

like what?

I integrated daily changes and I have a lot of simple questions. I'm quite sure that people would be interested by the answers
to these questions. But for the moment I will not tell them but I want to know what you guys are asking yourselves.

What does this relate to in the bug-tracking system?
Did the tests pass before?
Do the tests pass now?
Which parts of this are real changes and which are just because somebody
felt it was important to reformat everything? :-)
What were those changes I just accepted/deleted because the cat was
stepping on my keyboard?

Thanks alan!

We want more.
Please log them next time you integrate something. I really a bunch of them. But I want to hear you guys!

Stef

On 23.11.11 22:30, stephane ducasse wrote:

I've always considered it important to have a set of code quality tests
which would run before code was checked in and accepted into a common
baseline. Tests that were more than SUnit or functional acceptance
tests, but which then took a bit longer to run. I'd like to have these
tests automated and run when merging. SmallLint provides a number of
these, and there are surely some other quality and metric tools around.

This may go a bit far, but since merging is part of a build process, I'd
also like to see whatever you do fit into a CRISP build:

*Complete, i.e. scorched-earth build
*Repeatable, i.e. consistent and reproducable
*Informative
*Schedulable
*Portable

FWIW

Joseph Pelrine [ | ]
MetaProg GmbH
Email: jpelrine@metaprog.com
Web:  http://www.metaprog.com

As soon as you introduce people, things become complex.

Hi,
in a previous company I worked we had something very similar to what
Carlos described. We used SmallLint to verify that no errors where in the
code (we extended SmallLint to be able to document false positives), we had
what we called programming rules that were run as SUnit tests before
integration and after integration, and we also had something we called
architecture tests.
The programming rules included simple rules like checking the numbers of
parameters, doing spell checking, that the initialize message is not send
for other object but the class, etc. up to complex validations for patterns
like the visitor, state, etc.
The architecture rules were oriented towards dependencies between modules
(applications in Envy), dependencies between systems, etc.
We had a process that defined when to run each type of test (tests were
categorized like functional, programming rules, architecture rules, etc
using different suites). For example if you changed something, first you
had to run the tests related to the changed module, then the functional
tests of all the system (around 23.000 test, ran in 7 minutes) then the
programming rules. After that the change was sent to the integrator who
used an automatic integration tool and also the architecture tests where
runned. Before closing the new release the version was uploaded to a fresh
GemStone image, and all the functional tests where ran in GemStone. If
everything ran correctly, the new version was released. The last steps
(uploading code to gemstone, running the tests, etc) are currently done
automatically in a build server using Jenkins.

This process allowed us to be very confident in the code we produced. Of
course that it took some time to do the whole integration cycle, that is
why sometimes when the release was an internal one, we could avoid running
the tests in gemstone, etc.

Anyway, it feels really good to have a process like that and it is still in
use. The programmers add new rules when they find mistakes they do,
sometimes to prevent errors in the evolution of the code (that is very nice
too... design decisions are made explicit through these tests), etc. So, at
the same time is a very "reflective" process...

Bye,
Hernan.

On Thu, Nov 24, 2011 at 5:49 AM, Joseph Pelrine jplists@metaprog.comwrote:

--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: hernan.wilkinson@10Pines.com
site: http://www.10Pines.com http://www.10pines.com/
Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina