alphaITjournal: Breidenbach - Getting to a Hire Level, Part Deux

link -> alphaITjournal: Breidenbach - Getting to a Hire Level, Part Deux

like the idea of asking them to code something before they come

Summary . Agile Transitions . User Groups . Thoughtworks Studios Community

link -> Summary . Agile Transitions . User Groups . Thoughtworks Studios Community

Agile Transitions is an open forum that allows community members to discuss a range of executive-focused topics, including IT governance, organization, budgeting and financing, risk management, HR issues and enterprise adoption and integration.

AppleInsider | Apple market cap tops Microsoft, is now world's largest tech company

link -> AppleInsider | Apple market cap tops Microsoft, is now world's largest tech company

Cool

Webcasts

link -> Webcasts

I will be doing a series of webcasts starting tomorrow at 12:00 EST

I figured this timing is the best because it allows people from Europe to the Pacific to have it within "working" hours.

 

The first webcast will be "The Ubiquitous Language is not ubiquitous". To join the meeting come to https://global.gotomeeting.com/join/153015861. It will also be recorded and placed online (viddler maybe?) to be posted on the blog after.

I will be doing one of these every week or two until further notice. Feel free to drop ideas here in comments for future webcasts

 

Greg Young podcasts

Fluent NHibernate 1.1 Released - Fluent NHibernate

link -> Fluent NHibernate 1.1 Released - Fluent NHibernate

Fluent NHibernate, a statically compiled alternative to NHibernate's standard hbm xml mapping.

I hope they added some support for the things we found missing.

But Sometimes Ask

As a followup to my previous post, the book Growing Object-Oriented Software Guided by Tests makes the point that you can't always tell sometimes you do have to ask.

Some reasons for asking include

• getting information from values and collections


• using a factory to create new objects


• asking objects about their state when searching or filtering

When asking though it is important not to expose the internal structure of your object. For example instead of this code

carriage.getSeats().getPercentReserved() < percentReservedBarrier

Try this.

carriage.hasSeatsAvailableWithin( percentReservedBarrier )

The method hasSeatsAvailableWithin asks the question you really want answered instead of asking for the information to help you figure out the answer yourself. Or in other words you write a query that describes the intention of the calling object not just the implementation. Doing this moves the behavior to the most appropriate object, gives it an explanatory name, and makes it easier to test.

CraftyFella's Blog: Syntax Highlighting with Blogger Engine

link -> CraftyFella's Blog: Syntax Highlighting with Blogger Engine

Wanted to paste some code in my blog without losing indenting

Train Wreck Code

I read something funny today in Growing Object-Oriented Software Guided By Tests. They were explaining the Law of Demeter (Tell Don't Ask) and they called it train wreck code. For example they showed this code

((EditSaveCustomizer) master.getModelisable()
  .getDockablePanel()
  .getCustomizer())
  .getSaveItem().setEnabled(Boolean.FALSE.booleanValue());

They called it train wreck because the getters are chained together like the carriages in a train. I have never heard that before but I thought it was pretty funny.

They recommended changing the code to something like this

master.allowSavingOfCustomisations();

They made a good point about the method name. They said it should say something about "what the method is for" not just "how it is currently implemented".

I ran into an example of this the other day. We trying to make a conditional more expressive so we changed this code

if (property !== "query")
{
  key.addProperty(property);
}

to this

var isNotQuery = property !== "query";
if (isNotQuery)
{
  key.addProperty(property);
}

The explaining variable what was put in to try and explain why we needed the conditional. When we looked at the code though it didn't really add much so we changed it to this

var isNotExtReservedWord = property !== "query";
if (isNotExtReservedWord)
{
  key.addProperty(property);
}

Now you can see that "query" is a reserved word so it was filtered out.

The Myth of the Super Programming Language

link -> The Myth of the Super Programming Language

Good Quote "dumbfounded by the towering monument to mental masturbation"

Eliminating Comments: the Road to Clarity

link -> Eliminating Comments: the Road to Clarity

I used to think commenting my code was the responsible thing to do. I used to think that I should have a comment for just about every line of code that I wrote. After my first read of Code Complete, my views changed pretty drastically.

The proper use of comments is to compensate for our failure to express yourself in code. Note that I used the word failure. I meant it. Comments are always failures.

My team keeps breaking their promises. What can I do?

link -> My team keeps breaking their promises. What can I do?

Execution – actually having the team get things done– requires people to :

1. Say what they will do 
2. Mean it (be committed)
3. Do it

Everyone likes to do #1. Only some do #2. Great teams also do #3.

This must have been in my subconscious when I asked the team to switch reporting continuous learning goal progress to the Friday stand up instead of one on one.

James Shore: "Art of Agile" Training Courses This October

link -> James Shore: "Art of Agile" Training Courses This October

James Shore consults and writes about high performance software development for teams who are willing to be great.

How does TDD affect design

I have heard many times the claim that you should try TDD because it helps you improve the design of your code. In fact many people claim the design benefit is more important the benefit you get from having an automated regression suite. However I have never been able to pin down how TDD helps your design. Reading Growing Objected-Oriented Code Guided by Tests I saw the first explanation of how TDD can actually improve design.

Thorough unit testing helps us improve the internal quality because, to be tested, a unit has to be structured to run outside the system in a test fixture. A unit test for an object needs to create the object, provide its dependencies, interact with it, and check that it behaved as expected. So, for a class to be easy to unit test,
the class must have explicit dependencies that can easily be substituted and clear responsibilities that can easily be invoked and verified. In software engineering terms, that means that the code must be loosely coupled and highly cohesive—in other words, well-designed.
When we’ve got this wrong—when a class, for example, is tightly coupled to distant parts of the system, has implicit dependencies, or has too many or unclear responsibilities—we find unit tests difficult to write or understand, so writing a test first gives us valuable, immediate feedback about our design. Like everyone, we’re tempted not to write tests when our code makes it difficult, but we try to resist. We use such difficulties as an opportunity to investigate why the test is hard to write and refactor the code to improve its structure. We call this “listening
to the tests”

So admittedly I don't think I understand all of this, but it gives me hope that the book will teach me more about these ideas as I go and I will learn to build better designs.

External vs Internal Quality

More information from Growing Objected-Oriented Code Guided by Tests. The book talks about external vs internal quality. External quality is how well the system meets the needs of its customers and users (is it functional, reliable, available, responsive, etc.). Internal quality is how well it meets the needs of its developers and administrators (is it easy to understand, easy to change, etc.).

It goes on to talk about how the different types of tests fall into these categories

Running end-to-end tests tells us about the external quality of our system, and writing them tells us something about how well we (the whole team) understand the domain, but end-to-end tests don’t tell us how well we’ve written the code. Writing unit tests gives us a lot of feedback about the quality of our code, and running them tells us that we haven’t broken any classes—but, again, unit tests don’t give us enough confidence that the system as a whole works. Integration tests fall somewhere in the middle.

I am not sure what type of test you would call our tests. My guess is it would be acceptance tests. The focus of our tests are mainly on making sure the software does what we would expect it to. The focus of our tests has not been on making sure the internal structure of our code is clean.

Lessons Learned: Five Whys

link -> Lessons Learned: Five Whys

Doing research on five whys. Don't want to lose this article again.

Unhandled Exceptions » Blog Archive » This I Believe…

link -> Unhandled Exceptions » Blog Archive » This I Believe…

Seems like a smart guy

Behavioral Interview Question Database

link -> Behavioral Interview Question Database

Behavioral Interview Question Database

Good example questions

Unit vs Acceptance Test

Found another good idea from Growing Object-Oriented Software Guided by Tests

When we’re implementing a feature, we start by writing an acceptance test, which exercises the functionality we want to build. While it’s failing, an acceptance test demonstrates that the system does not yet implement that feature; when it passes, we’re done. When working on a feature, we use its acceptance test to guide us as to whether we actually need the code we’re about to write—we only write code that’s directly relevant. Underneath the acceptance test, we follow the unit level test/implement/refactor cycle to develop the feature

We have had the question come up a couple times about whether we should be writing unit tests and acceptance tests and what happens if they overlap. It seems like the book is advocating you do always do both. You write the acceptance test to guide you on whether you actually need the code you are about to write. The acceptance tests also show demonstrable progress on customer features. The unit tests support the developers by helping them write high quality code and protecting against regression failures while refactoring.

The book also recommends that acceptance tests should be end-to-end tests meaning they interact with the UI and not call directly into the code. On every check-in they

1) check out latest version
2) compile code
3) run unit tests
4) integrate and package system
5) perform a production like deploy into a realistic environment
6) exercise system through external access points by running acceptance tests

TDD Why Not?

Starting reading a new book "Growing Object-Oriented Software Guided by Tests"

The catch is that few developers enjoy testing their code. In many development groups, writing automated tests is seen as not “real” work compared to adding features, and boring as well. Most people do not do as well as they should at
work they find uninspiring.
Test-Driven Development (TDD) turns this situation on its head. We write our tests before we write the code. Instead of just using testing to verify our work after it’s done, TDD turns testing into a design activity. We use the tests to clarify our ideas about what we want the code to do. As Kent Beck described it to us, “I was finally able to separate logical from physical design. I’d always been told to do that but no one ever explained how.” We find that the effort of writing a test first also gives us rapid feedback about the quality of our design ideas — that making code accessible for testing often drives it towards being cleaner and more modular.

On all the teams I have been on "Tests" have always been a dirty word. Something you do because you are supposed to not something you do because you take pride in it. I hope the book goes into more about how TDD can help your designs. I think most people I work with do take pride in their designs and are always looking to improve in that area. Seeing TDD as a technique to improve designs might be something people could be inspired by. I think it will take more evidence though than just one statement.