Comments for One brike at a time

Comment on The state of my testing art by One brike at a time » Blog Archive » Adding ‘given a’ to rspec

Tue, 16 Feb 2010 17:41:31 +0000

[...] the past few months I have grown to like the ‘given a’ syntax more and more (described here). So when I recently reactivated my Ruby On rails home project (see brikeyard deployed on heroku), [...]

Comment on The law of two feet by Miki Saxon

Miki Saxon — Wed, 13 Jan 2010 18:35:37 +0000

Hi Denis, I saw this article because of a Google alert that hit my inbox today. timely, huh:)

Please accept my belated congratulations on your move as well as a far better understanding of the underlying ‘why’ than I usually hear.

I realize that you are very forward thinking, but it would stil be nice if you would add an email subscription for those of us who hate RSS.

Comment on Test Driven Development and Design by Contract by Hering Cheng

Hering Cheng — Sat, 02 May 2009 04:51:22 +0000

I agree that it would be great to link or unify TDD and DbC. I think only the most simple of contracts (i.e., defensive programming) can be enforced via automation (e.g., as a crosscutting concern with AOP), such as checking the validity of actual arguments to functions. The rest of the assertion statements (the most commonly used tool for defensive programming) is probably too specific to each piece of code to be generalized.

BTW, here is a related claim I make: Strongly-types languages “automatically” provide a layer of defense or tighter contract whereas more dynamic languages require one to code more defensively.

Comment on The enemy within by Hering Cheng

Hering Cheng — Sat, 02 May 2009 04:34:20 +0000

I want to address defensive programming specifically. I do not think it is related to the caliber of our fellow teammates. The whole theory of specifying pre- and post-conditions, plus loop invariants, is to ensure the correctness of and to expose the assumptions inherent in code, even within our own code. We need to push for more defensive coding, with ample use of assertion statements.

Comment on BayAPLN open space on Technical Debt by Chris Sims

Chris Sims — Sat, 25 Apr 2009 14:58:58 +0000

I still think that “Is Technical Debt the Dark Matter of Software ?” wins the award for best named session of the evening.

’twas my please to pick your name.

Cheers,

Chris

Comment on Configuration and the lack of design by Miki

Miki — Mon, 16 Mar 2009 06:02:54 +0000

Hi Denis, You have been awarded the Lemonade Award by Miki Saxon at MAPping Company Success. Click here to see what that means and what happens next.

Comment on QCon San Francisco 2007 – Final Notes by Beijing Open Party » QCon?????????????4?7???

Beijing Open Party » QCon?????????????4?7??? — Thu, 19 Feb 2009 03:13:49 +0000

[...] ???QCon???????????InfoQ???????????????????????????????????QCon?????????????????? David Forbes——????????????????????????????????QCon????????????????????????????????????????????????????????Westin??——???? Denis Bregeon——??????????????????????????????????????????????????????????? Srini Penchikala——??????????QCon ????????????????????????????????????????????????????????????????????????? Alex Olaru——??????????????????????????????????????????????????????????????????????? Pete Lacey——??????????????????????????? [...]

Comment on Bug Management by Denis

Denis — Sat, 14 Feb 2009 01:36:34 +0000

No I cannot really provide the information you request.

As for the P3 and below, they are absolutely a debt of some kind. They are actually IOUs given by the development team to the users. We know that most of them will never be repaid.

In my experience, there are two efficient strategies to eliminate this debt: constant refactoring supported by tests and bundling bugs in an area with new work in the same area.

I like the idea of making the bug visible in the code or in the tests. It may be interesting to maintain a list of failing tests rather than bugs reports !

Comment on Bug Management: Auto expire defects. by Denis

Denis — Sat, 14 Feb 2009 01:31:38 +0000

The idea behind this is to avoid wasting time going over endless lists of irrelevant bugs. The time would be better spent going over the list of new features.

Autoexpire would ensure only fresh bugs are prioritized.

Comment on Bug Management: High priority to released defects. by Denis

Denis — Sat, 14 Feb 2009 01:28:58 +0000

Release notes although lately I made a point of sending an email with the link to the artifact generated by their feedback. This is not satisfying. RSS feeds or automated emails would be better.

As for expected cycle time as we discussed off line it really depends on your users. I think in the financial sector a cycle of a month is acceptable. A daily or a weekly patch (which is what Bloomberg does) would be ideal. And with a good development process it is very manageable.