Search The Blog
Latest Posts
from 5whys.com
Twitter: @RoyOsherove
About this site

TDD in .NET Online Course

TDD and BDD in Ruby Online Course

 

Subscribe!

This site aims to connect all the dots of my online activities - from tools, books blogs and twitter accounts, to upcoming conferences, engagements and user group talks.

Monday
Oct142013

Video - Refactoring and Design Skills for Test Driven Development

Last week I presented a keynote and a talk at the London Software Architect conference. Here is the video I recorded from my laptop during my talk about refactoring. I hope you find it useful.

Thursday
Oct032013

Looking for promising .NET developers for my current project

I am currently in Norway, Oslo area, and involved in a very interesting project. Both architecturally and in terms of teams and cross communication of a big product. We are looking for good .NET developers to join, who I can then pair with and coach when they join.

If you are interested in joining the company, and live in Scandinavia, please contact me to email  roy at osherove.com.(no remote work)

Sunday
Sep152013

New Online Course: TDD and BDD in Ruby

If you are just coming into the Ruby community, you might think “man; everyone here does unit testing and TDD already”. But the truth is, that is very far from reality. Most people in Ruby seem to talk the talk, but very few that I’ve seen actually walk the walk.

Yes, many of them do have tests, but very few do things test driven. It’s just very difficult without a guiding hand sometimes. So many developers slack off and write the tests after.

Worst, many developers do not know how to write anything but integration tests. There is lots of good stuff in integration tests, but they can also be very slow for a good feedback cycle.

Unit testing is necessary to learn, and doing things test driven can make you more productive in the long run (I discuss some numbers during the course).

YOU DO NOT NEED ANY PREVIOUS UNIT TESTING EXPERIENCE.

I will teach you from zero how to write your first unit test with RSpec (and why RSpec) , all the way to making you a master of the craft with mock objects, stubs, and how to choose an isolation (mocking) framework.

You will also learn about making a continuous delivery solution and some patterns for getting started with a project on the right path.

Monday
Aug192013

Book & Audio Book: Notes to a Software Team Leader

If you are a software team leader, architect, scrum master or project leader, you might be interested in the book Notes to a Software Team Leader which I have just finished.

The book contains important techniques and notes from some of the most thought provoking leaders in IT these days: Uncle Bob Martin, Dan North, Johanna Rothman, Kevlin Henney and many more.

Now, you can also listen to the book on your iPhone or Android. I had the book professionally narrated. You can listen to a sample of how it sounds on the audio book link below.

The book is available in two formats: 
An ebook 
An Audio book (4+ hours)

Here is what it sounds like:

 

I am also running workshops on team leadership in software. Here are some of my upcoming stuff:

Thursday
Jun202013

Be a Book Reviewer for 'Notes to a Software Team Leader'

Want a free book? Willing to review it on Amazon when it is published? Willing to give me valueble feedback?

Fill out this form.

Monday
Jun102013

Fix: PhantomJs, YSlow and Loadspeed load pages very slowly on windows machines

I was running into this problem. We were using phantomjs to run speed tests and weight tests for our web pages, and it all worked well on my machine.

Then it worked VERY slowly (five times slower!) on the build agent.

The fix was simple, once I single handedly googled it.

Go to Internet explorer on that machine.

  • Click internet Options
  • Click Connections
  • Click Lan Settings
  • UNCHECK “Automatically detect settings

As an extra measure, you might want to disable IPV6 on the Ethernet adapter. Seems to fix it for some people.

Thursday
Jun062013

Coming to America (to do training)

After a long standing bureaucratic battle with the US immigration authority , I finally have a visa to come to the US, and it expires DEC 2nd 2013 (in a few months… I know..)

I would like to make the most of this ability to come visit the US. Legally I cannot charge a fee for doing training in the US, but I CAN charge for the training materials you will receive.

Here is a list of possible trainings. I am also happy to add to that JS Unit Testing And TDD classes, and Ruby TDD and Unit Testing Classes. I will write more about those later today.

So: I am happy to provide FREE training (only materials cost money) to companies in the US in this time frame. If you would like me to come over from Oslo, visit for a few days, and do any of a number of possible training options, or if you would like to arrange a PUBLIC course somewhere, I am happy to arrange it as quickly as possible.

Contact me (and read my payment terms)

Tuesday
Jun042013

Ugly Code Means Your Product Used to be Successful

I have now worked at a bunch of companies, and consulted for quite a few. I have looked at some pretty horrible code.

Every company I visit with say the same thing:

“Yeah, but our code really sucks. “

It does not suck any more than other code I have seen. It usually sucks just about as much.

Do a thought experiment:

Of the ugly code you’ve seen, when was it written? How long has it been alive? 

Most of the time, I have seen ugly code that started a good few years ago. I have also worked in companies that practiced TDD and unit testing, and still had ugly code. Their code did NOT start out with unit testing, and was just as untestable and hard to read and lots of the code you see in your own place.

If you ‘hack away’ code and it suddenly becomes successful, you hack away even more. and then suddenly, it is 2 years into the product’s life, and now it is becoming increasingly hard to maintain. NOW you also realize your code really sucks, because it was never intended to be a long lived piece of code, it was always a type of experiment to see what would happen; Would people really like it?

And then they did, and then there wasn’t enough time except to take money, fix patches and live.

And now it’s time to pay all that technical debt, and that is a good thing, because if you find yourself in technical debt,  it means your product has gone through its trial by fire, and now it is growing up to become a real boy.

So do not feel bad your code used to suck. You’re doing something about it now, right? it was just in its puberty, when you needed to focus your efforts on making sure you’re on the right path.

When I am in a startup, I usually do not write tests until I feel that

  • I know how to build what I am trying to build.
  • I know customers really want what I want to build.
  • I know the code I write will live more than a month.

 

Until then, I think of things as a big prototype, but unlike other places, I am not afraid of throwing it away, but I am also not afraid to accept the fact that some hackity crap code will enter during the experimentation process.

Does this mean you have permission not to write unit tests? YES, IF the main focus in your head is to get feedback that you are building the right thing. Once you know it is the right thing, not doing automated tests is very foolish.

Web Analytics