headers
Emily Bache | 20 May 2013 09:19
Picon
Gravatar

[ANN] The Coding Dojo Handbook

Hi,

I've been thinking for some time about how to get average software developers in ordinary companies to learn practices like Test Driven Development, and I've been experimenting with the Coding Dojo format for teaching and learning. I've just published an ebook, "The Coding Dojo Handbook" which aims to be a helping hand along the way. My thought is that a team lead or enterprising team member could organize Coding Dojo meetings with their colleagues. This would provide a space for the whole team to discuss problems and issues around TDD, and to practice some of the basic skills involved. And it's fun!

In the book I have lots of practical advice, collaborative game suggestions, funny stories about dojos, and a catalogue of Kata exercises to draw on. I think it should be a useful resource to anyone starting a new dojo, or to get new ideas for an existing one. If you're in either of those positions, I hope you'll consider getting a copy.

https://leanpub.com/codingdojohandbook

If you've already read the book, please note I now consider it "finished", and have probably substantially updated it since you last looked at it. In any case I hope you'll check the latest version, and consider posting a review of it in your blog.

Regards,
Emily Bache

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 0 comments |
headers
Phạm Anh Đới | 7 May 2013 11:36
Picon

Can we submit Vietnamese version of Manifesto?

Dear all, 

We are a group in Vietnam. We have vision to build a agile community in Vietnam. We have translated manifesto of software craftsmanship into vietnamese. Can we submit it to http://manifesto.softwarecraftsmanship.org?
Regards

Đới PA

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 1 comment |
headers
zdsbs-/E1597aS9LQAvxtiuMwx3w@public.gmane.org | 30 Apr 2013 22:18
Picon
Favicon
Gravatar

May 6th next Boston SC - Practicing Modeling

Hi All,

Then next Boston SC meeting is May 6th (Next Monday!) We'll be practicing modeling http://gathers.us/events/may-boston-software-craftsmanship-meeting

How many different modeling ideas do you come up with before you settle on one to implement? How often do you let your model concepts emerge from TDD?

Tonight we'll be putting aside TDD & code all together. The goal will be to stretch how you conceptualize what you'll build in software. You'll be presented with a concept to model and will work on a number of ways to model it.

This should be a blast and did I mention you won't even need a computer?

See you then,

Zach
Boston SC - Improvement through practice

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 0 comments |
headers
Matthew Riley | 23 Apr 2013 03:20
Gravatar

Perception that high quality equals Rolls Royce

Hello everyone,

My team has been involved in developing an iPhone application using Agile methods with a very high degree of test automation.
We have successfully delivered the project with a minimum of defects and we are proud to have accomplished this.
The business manages a number of other software projects outside of our team, not using Agile methods, have a lot of defects and a lot of manual testing.
With this contrast a perception has formed that we build the Rolls Royce of software which may be overkill for their needs.
What they are really saying is they may not require the level of quality we have built into the software and may be willing to compromise on quality.
Throughout the course of the project, we have been trying to educate the business on the benefits of these approaches, with limited success.
It's obviously very difficult to prove the benefits objectively to non-technical people, and there's absolutely politics at play.
I doubt very much this is a unique situation. Has anyone had any success managing this scenario and how did you go about it?

Thanks, Matt

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 34 comments |
headers
Michel Löhr | 24 Apr 2013 10:00
Picon
Gravatar

Typo in german translation of Softwarecraftmanship Manifesto

Regarding expecting high quality it hits me as a non-native german speaker to notice a typo in the german translation of the manifesto:


The translation of the word "Mehrwehrt" should be "Mehrwert".

Who can update this on the webpage? http://manifesto.softwarecraftsmanship.org/#/de

Cheers,
Michel

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 2 comments |
headers
Raoul Duke | 18 Apr 2013 22:45
Picon

domain vs. flexible vs. correct-by-construction

say -- purely hypothetically, mind you!!! -- somebody gives you a spec
or two of sorts about an app they want made. it lets you Add and
Subtract. you write the data model stuff. turns out Add and Subtract
are the same thing just with a different sign on the value, so you
make a Delta class.

 then they project changes. somewhat. how much does your code have to change?

i was (hypothetically) trying to make the data model and api be
closeish to the domain, in a correct-by-construction style. like, the
original spec said you could add or subtract. now you can only
subtract. so the data model class i had that was called Delta should
go away, and i should only have Deduction, and it should assert that
the value is constrained appropriately. that kind of thing.

yes, i could add a layer on top that supports the constraints. but
then i'm making extra code for no real purpose at the moment.
shouldn't we only write as much as we need to? (therein lies the
subjectivity rub).

so anyway all my apis and tests need a fair bit of rework because the
assumptions have changed. yes, this is brittle code from one
perspective. from another perspective, it is an api that tries to make
things safer and more clear to the eventual user of it.

how do you personally dial in such things yourself? how do you know
when you can nail things down? how do you know what is too flexible?
how do you know what is too much code? etc.

sincerely.

--

-- 
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe@...
To post to this group, send email to software_craftsmanship@...
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Permalink | Reply | 0 comments |
headers
Marcus Milanez | 16 Apr 2013 17:59
Picon
Gravatar

TDD Classification

Hello everyone,

I'm conducing my masters research on TDD (more specifically, on the economical, psychological and technical aspects of TDD) and came across some questions that are making me feel confuse.

The first one is: How exactly can we classify TDD?

On Kent Beck books we can find that TDD is a development technique/style (TDD By Example). Robert Martin says that it is a discipline (Clean Code). Martin Fowler says that it is a design technique (http://martinfowler.com/bliki/TestDrivenDevelopment.html).

My question is: Assuming that TDD is a technique/style, what are the other existent techniques/styles available for proper comparison ? How about disciplines. is there a list of available development disciplines that I can query ? What are the other known and documented design techniques?

On WikiPedia (http://en.wikipedia.org/wiki/Test-driven_development), TDD is classified as a "Software Development Methodology" but in my humble opinion this is not accurate. The definition of software development methodology as described by Ian Sommervile in "Software Engineering" is: "... a set of structured approaches to software development which include system models, notations, rules, design advice and process guidance.". This definition seems to be appropriate for Software Development Life Cycle models such as Waterfall, Spiral and Scrum, but not TDD. Does that make sense?

While thinking through this, I started thinking of TDD as a problem solving strategy but this is not clear enough for me.

As always, thanks in advance!


--
Marcus Milanez

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 45 comments |
headers
Ashok Guduru | 12 Apr 2013 05:39
Picon

How to coach or mentor software craftsmanship

Hi,

 
I don't know whether asking this question in this group is good idea or not but I'm posting here because it is related to software craftsmanship.(SC). My question is as the title says... What is the best way to teach/coach/mentor/train to the developers within an organisation? 

I recently joined a new software development organisation as technical architect. There are many isolated teams working on different projects on different technologies like .NET, Java et.al.  It's almost 4 months passed joining me and I worked closely with one team and occasionally got involved with other teams when solving a particular problem. I clearly noticed the same problems they're facing due to deficiency of SC. There are mixture of developers with different age and years of experiences. Even with different title like Jr. Dev, Sr.Dev, and Tech-Lead etc. but I see this SC is clearly missing in them.

I know much about SC and I do practice & care about it. In my career I clearly saw huge advantage and gain in speed of the development and quality. I tried 3 to 4 times to explain & train them by assembling few teams in a conference room but not able to swallow them this SC thing!. For example, I saw in their regular meetings & conversations they frequently use 'Refactoring' word. When I asked what do you mean by that? I stumbled up on hearing their reply. They use it for something completely different purpose. I saw they don't know the real meaning, activities it involves the names and the smells etc. One day I took one session to show what is real Refactoring is. I pulled one of their code-base picked-up a method in a big class and did Refactor!. There are almost 19 lines that method and when completed there are only one line remained!. They said they'll do it when they find Time!!!  - lol...

I see there are many problems from management side also. So what would be the best way to induce these skills in them. I would want to make think about the importance of the software quality, importance of the internal quality as the quality of external visible things. Be passionate about the quality in things they do daily. Be professional about their profession.

Thanks.

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 5 comments |
headers
Tomas Malmsten | 1 Apr 2013 22:12
Picon

Visualising Technical Debt

Hello all,

I just wrote a blog about how I have visualised technical debt to non-technical stakeholders using a special type of backlog items. I would be grateful for your feedback.

http://www.tomasmalmsten.com/2013/04/visualising-technical-debt/

Regards

Tomas Malmsten



Avega Group 

switchboard +46 40 10 51 00 | direct +46 40 10 51 31 | mobile +46 72 5150 121

Gustav Adolfs Torg 45 | 211 39 Malmö

Homepage: http://www.avegagroup.se/
Twitter: https://twitter.com/tomasmalmsten
Blog: http://www.tomasmalmsten.com/
LinkedIn: https://www.linkedin.com/in/tomasmalmsten


--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 0 comments |
headers
Nigel | 31 Mar 2013 18:30
Picon
Gravatar

Re: Questionare for Agile Research

I die a little inside when I see questionnaires with questions like: "We use standard and well-defined code in the projects." or "Being of shareholders has an important role in the success of an agile project."


AgileBorat?

Fox
-- 

On Wednesday, 6 February 2013 17:15:44 UTC, Doug Bradbury wrote:
I've been contacted by a masters student doing some research on Agile methods.  He's asked me to post this to the list.

Doug

-----------------------------

Hi

I am master student.

The questionnaire for the evaluation of the success factors in
software projects is based on Agile approach. 32 factors were
identified based on various articles.

The 32 factors were considered in terms of 32 questions. The answers
were then analyzed and the final success factors are identified.

If you can help me on this I am very grateful.

http://agilequestionnaire.behnamhosting.ir/

Good luck

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 0 comments |
headers
Philip Schwarz | 30 Mar 2013 16:19

software craftsmanship is not gold plating; it is professionalism

I just bumped into the following tweet:  <at> johannarothman SW craftsmanship is not gold plating; it is professionalism. It allows us to deliver fast <at> RonJeffries <at> chethendrickson #AgileIndy2013


Does anyone have anything to share about this?

Philip.

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to software_craftsmanship-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Permalink | Reply | 8 comments |

Gmane