OrthoCoders

You can code it, I can help!

Modern Hiring

Lately I been hearing many companies complain about how hard is to find developers.

I do agree, finding good people is extremely complicated.

But not only because perhaps there’s a shortage in the city. Also hiring processes are out of date, driven by the wrong people and produce poor results.

I have done my share of interviews trying to find the right candidate for a position. Let me share a bit of what I learned…

Kanban Limits

Model your process

Probably by now if you work in the software industry you heard about the word kanban or already are using a Kanban board with your team.

A Kanban board (usually implemented using a whiteboard, wall with stickies, or electronic version) lets you model the series of steps that as a team you have to take in order to produce working software.

Some of the benefits are that you gain visibility, communication and transparency in one simple step. And if you use it right you will be able to show bottlenecks and cope with them or at least elevate the issue to someone that has the power to solve it.

Most important is that you can focus on working based on your team capacity (Pull) vs. working by demand (Push).

However today I don’t want to do a 101 post on Kanban. There are plenty of posts for that, you can find them here, here and here.

Today I want to talk about what is the result when, once you read that intro, decide to implement Kanban with your team. What happens next?

I Wrote the Test, Now What?

Working with state

In the previous post I showed some examples of writing specifications using immutable classes. For an introduction to specifications please refer to my post about testing.

There’s no denying that immutability can provide lots of benefits in terms of testing, reducing complexity and lowering coupling. Having a language/paradigm that embraces it could be a huge productivity booster.

Unfortunately that’s not always the case or our choice to make ;).

Method Specification

Stateless

In the previous post I introduced the Precondition and Postcondition concepts. Today we are going to explore some examples and see how the specification (pairs of pre and post conditions) will guide our tests.

Let’s start with methods that don’t depend on the instance state, usually called static methods.

Hip to be Square

Consider a method Square that takes an int and returns the square:

1
int Square(int x)

What is the Pre? What do we need in order to run Square? Not much, any int should do. So I just want to indicate that x has a value (any value) by using the constant X0: