A more important distinction is whether the unit you’re testing should be isolated from its collaborators. Imagine you’re testing an order class’s price method. The price method needs to invoke some functions on the product and customer classes. If you follow the principle of collaborator isolation you don’t want to use the real product or customer classes here,
The Agile Manifesto says “Deliver working software frequently”. Learn to do that. The rest will follow.
Lately I’ve been inundated by people talking about how you need “Lean Principles” in addition to “Agile” in order to be successful. I’ve been swamped by people asserting that teams need to have hooks and ways to decide which “Agile” meetings or rituals to add or remove from their work.
while ago, I wanted to get a little quick feedback on some data I was playing with, but the day was almost over and I wasn’t done working on it yet. I decided to tweet my rough draft of a graph of GitHub language trends anyway, followed later by a slight improvement.
Some of our teammates including Ryan Means, Tyler Poschel, and Austin Pernell (and a cameo by Sean Beach) at the Hack Nashville event this past weekend (May 2 – 4). They teamed up together working on an interesting product idea that they will share about soon.
Every minute of the work day is an opportunity for investment for us as developers. During this time, we can make a conscious decision to grow in our craft or instead chose to stagnate. Sadly many developers make the decision to get comfortable with a set of skills and not push forward. Many organizations are filled with these developers.
There is an alternative to this. Many developers actively choose to invest their time in targeted efforts to mature in their craftsmanship and innovate their technical skill set. To the surprise of many tech bloggers out there, this process often includes growing in areas which are not tied to a specific language or platform.