Morning greetings

I work for DreamWare. We greet each other with a handshake or a kiss on the cheek every morning (well, it's a kiss only when at least one woman is involved). There are occasional hugs, too. We are happy to see each other and we are not afraid of letting others know it.

How we plan to use Trello for Scrum

No

Trello-Office

• Time spent and estimated
• Burndown chart
• Last release: v1.3 2014-02-16
• No website, no source

TrelloCRM

• No screenshot
• Based on Scrum for Trello
• Last release: 1.87, 2014-06-11
• Links to developers provided
• Not really suitable for project management

Scrullo

• Last release: 2013-01-02
• Wrong github link provided
• Looks inactive

Points for Trello

• Points are not always calculated
• See Points for Trello - Combined edition for a more stable implementation

As an addition

Background Colors Cards for Trello

• Uses only the six colors available for labels
• When a card has more labels, the rightmost color is picked
• Use it as an addition to a project management extension

Kanban WIP for Trello

• You can add WIP limits to lists
• The list becomes red when you exceed the set limit
• Open source: https://github.com/NateHark/TrelloWIPLimits

Progress for Trello

• Display a progress bar using cards or points from Scrum for Trello or checklist items
• Open source: https://github.com/Cycododge/Progress-For-Trello

Trello Card Dependencies

• Graph visualization
• Click on cards to add or remove dependency between them

Projects for Trello

• A card can be tagged with multiple project names
• You cannot view cards for a tag
• Based on Scrum for Trello
• Open source: https://github.com/agebase/projects-for-trello

OGD’s enhancements for Trello

• Summarize points
• Different display of cards without points
• Highlight cards with label color (they call it separator cards)

Ultimello

• Sort cards by title, votes, due date, labels
• Save cards in sorted order or revert to original order
• Developer’s email provided
• No source

Maybe (in descending order of how sophisticated it is)

Plus for Trello

• Most sophisticated

Points for Trello - Combined Edition

• Add points to card title, sum of points are displayed for each list, grandtotal for the whole board
• Three types of points, depending on the parenthesis used
• Based on Scrum for Trello and Points for Trello
• Open source: https://github.com/jgraglia/Trello-Points

Scrum for Trello

• Source: http://github.com/Q42/TrelloScrum
• Summarize points for a list and for the whole board
• Two types of points, depending on the parenthesis used
• When cards are filtered, only the points on filtered cards are summed

The selected combination

• Scrum for Trello
• Plus for Trello
• Projects for Trello
• Card colors for Trello

Big refactoring

I started to refactor a file of a few hundred lines of code. I had a vision how clean it will look. It took more days until I realized it takes more time to refactor the whole file. My tech-lead suggested to cut the task which I did and refactored only one class. It became really cleaner. It could've been used as a base class but people didn't use it but continued to use the quick and uglier way of the other classes.

I started to refactor a file of similar size now because it always takes some mental effort for me and for me coworkers to understand the structure of the file. It was written by one of the coding heroes of the company, it's dense and tangled and still verbose at the same time. It takes a few minutes to run all the tests for it so I made a relatively big change that didn't look harmful, I was just factoring out some helper functions. When I finished, I ran the tests and they failed. I got frustrated. It took me quite some time to find out that I had forgot to set an environment variable before running the tests. There was even a warning printed that could've suggested that but it was lost in the many lines of other logging output.

Who commits to deliver the least Kanban points

We set up a Kanban-board. We start every week with a commitment, team members make an estimate how many points they will have done by the end of the week. Points are not measured as working hours because it would be different from person to person. We try to have a common measure of complexity points, it doesn't have a specific meaning, it's just an abstract unit. We just had enough planning session together so that two team members will probably give a similar estimate of a task in complexity points. This is further reinforced by the weekly feedback session when we sum up the actual points we delivered and talk about what had caused the differences between the estimated and the actual values.

The commitment phase is pretty frustrating and painful for me because it's usually me who says the lowest number. It makes me feel dumb and incompetent.

Programmers as seen by an HR manager

I know these are generalizations, but...

• Good programmers tend to be good musicians
• They give straightforward answers, sometimes at the cost of hurting other people's feelings without intending to
• They grasp the general structure and the gist of complex issues
• They want to find a solution right away
• It's difficult to find out what they're feeling in a situation. It can be pretty difficult for their managers.
• They avoid conflicts and other emotionally loaded situations
• They don't want to be (perceived as) nosy
• They are afraid of being seen assholes or using their power. That's why they lean on having a laissez-faire attitude.

If I attended a conference on programmers' psychology, I'd expect to hear some stories. For example how a newly appointed manager overcame a difficult situation. Or how an introvert junior developer can share his or her ideas with the team.

Important things I don't do

I'm going home now because a guy is coming to fix the heating system. I'll work from home for a few hours. I'll take some notes for my research which I don't do at the office. It would be quite appropriate to take notes about my life as a software engineer while being in the office but I still don't do that. Just like going out to the gym to work out which I also don't do. I am considered to be a mature adult who can use his time, I'm free to come and go to the office any time. There are even some guys who have a special schedule like coming to the office only in the afternoon and work until late night. Another guy goes to late night parties one day, then takes a day off, then works two days without a stop. And I know of others who have similar issues as mine, they don't do things they find important.

I also notice while eating that I had enough but I carry on eating.

Research on programming psychology

I hereby declare that I started my research on programming psychology. It doesn't have a clearcut definition yet but there is probably a common understanding what it could mean. Software engineers prefer to talk about... er... software. They may even talk about how much they love or hate a notion, such as a programming language or a framework. They will list certain attributes to justify their love or hate but they rarely talk about their emotions per se. As one of my co-worker half-jokingly put it, he doesn't share more of his emotions because he doesn't have that much. So the psychology of programming deals with issues programmers don't deal with.
I have two goals with this research. First, I want to get into the top ten of some area. Since I avoid competition, it has to be some really weird area where there aren't many competitors. I also want this area to include as much of my skills and interests as possible. There are many awesome programmers. There are plenty of great psychotherapists. But there are really only a handful of people who are good programmers and good psychotherapists at the same time. That's my territory.
My other goal is to expand programming experience to include other sides of human nature. There is some talk about coding as an art, being in the zone, the importance of having fun while coding, etc. Some programmers even go to coding dojos or retreats or record a screencast of their performing a kata. My dream is that one day programmers will code love poems to their partner, dance a difficult algorithm to fully grasp it and meditate at the keyboard. One day a senior programmer will just set up a little game of castles and dragons and their junior will love to solve it which will be the resolution of an underlying software task. So my other goal is to make those days come a bit closer.

SMART goals vs organic growth

I suppose there is a book on goal-oriented activity vs organic growth. This is a short review of that possibly fictional book.

The basic idea is that there have been two ways of being in the world. One can be characterized as putting Man in the middle. The most important question is what Men want and need, what Men can achieve and get. The other way of being puts Man to the second rank, removes the capitals and claims that men are subordinated to X. What X is depends on many things, it can range from the greater good of humanity to God.

Image by Seier https://www.flickr.com/photos/seier/1244185274

Both approaches have inspired people to create wonderful buildings, books, and gadgets. And both approaches contributed to bloody wars and injustices. So none of them is right and none of them is better. Both have their strengths and their weaknesses. They have a lot to learn and borrow from each other and this is very difficult sometimes.

There are ages when the one has a lead, at other ages the other has the upper hand. The Medieval Age in Europe was about subjecting ourselves to a higher entity. The Renaissance turned it upside down.
Religion belongs to the organic growth approach most of the time, it emphasizes that the rules of life are way too complex for us to completely understand them. We are small balls on a huge snooker table of greater forces. It’s not something we should be sad about, those balls can have a full and wonderful life. They are just not the main characters or directors of the play.

Rationality, on the other hand, has typically a goal-oriented world view. That’s the dominant and powerful ideology of our age. Since it doesn’t trust any higher forces to arrange things for us, it needs to invent methods to do that. Ethics is replaced by management. What shall we do to others? It’s a question of how me manage them. What shall we do to our life? It’s a question of how we manage ourselves. Spirituality is replaced by goals, even SMART goals. SMART is an acronym that stands for Specific, Measurable, Assignable, Relevant, Time-bound.

The first part of the book goes to great lengths to analyze the two sides of this dichotomy. A number of issues are discussed from both view points. My favorite chapter is about how we make decisions based on these models and how we justify them. The modern way to evaluate an option is to use what the book calls economic justification which is based on a simple (and flawed) syllogism.

If people buy more of something, they think it’s more valuable.
If many people consider something valueable, then it is valuable.
–
If people buy more of something, then it is valuable.

The second part of the book takes an unexpected turn. It’s basically about software companies and their methodologies. Traditional software development is considered to be an example of a goal-oriented activity with lots of process, systems, all measurable and managed. The Agile turn gave rise to dynamic startups that have a different mindset. They say mantras, like Release early and often which may result, oh horrors, in missing features and buggy code. They say, YAGNI, short for You ain’t gonna need it, when a smart guy implements something for the sake of a possible future request.

But agile startups haven’t realized yet they differ not only in their methodology (and budget), but also in their philosophy. They are to become the new advocates of organic growth. To grow software organically is a humble and controversial approach. It basically says, don’t plan large systems, because they are impossible to implement. Create a small program, share it, find a place in the large ecosystem where it fits. This is exactly how open-source components and repositories work.

The last chapter of the book is a bit inconclusive. What I like about is the idea that software development will fully recognize its potential when the SMART goal will have its organic counterpart. Let me give it a try how it would sound

• Holistic
• Subjective
• It’s done by many people, some of them even anonymous
• Dreamlike
• Take your time

Testing with clojure.test and midje

This is the next part of my introductory Clojure terminal casts

Clojure: from not knowing it to testing a web service with it

See also Part 2, Testing with clojure.test and midje

Plain text screencast

“How do you install a foobar-quux?”, you hear it from the other side of the desk. “It’s easier to do than to explain”, you respond grabbing your keyboard. A few lines in the terminal and it’s done. You hesitate for a moment to write a neat script of what you’ve just done. But it’s not that easy, because… And it’s not worth it once you’re done. Until you hear the same question again in a week, “How did you install that foobar thing? It looked so easy, but I forgot.”
If you had a really lightweight screencast tool at hand which does nothing fancy, no screen resolution and frame rate settings. Just record what I do in the terminal.
The funny thing is this simple tool exists. It’s pretty old, actually, its first version was released in 2000. The original one is called ttyrec. It has quite some spinoffs. You can even upload it to the web and replay in the browser. I found more sites offering this service

• Shelr.tv
• PLAYterm
• asciinema

My favorite one is Shelr.tv where you can change the replay speed.

Rules to write functional Scala code and stay sane

Use only cases classes from the OOP world

Well, with some exceptions that will follow soon. But the baseline is: no regular classes, no inheritance. A case class can be considered an abstract data type, so it can serve as a container. Another use case for them can be seen as a little weird form of currying.

val people = List("Bob", "Mary")

// functional
def join(separator: String, list: List[String]): String = {
  list mkString separator
}

def joiner(separator: String) = {
  (list: List) => join(separator, list)
}

joiner(",")(people)

// with a case class
case class Joiner(separator: String) {
  def join(list: List[String]) = {
    list mkString separator
  }
}

Joiner(",") join people

Use traits only to simulate union types

There are cases when an instance can be one of two types, for example a tree node can be either a branch, or a leaf node. If we follow the above rule of using only case classes, we’ll be in trouble. This is where we can use a trait shared by some case classes.

trait TreeNode {}

case class Leaf(value: String) extends TreeNode {}

case class Branch(left: TreeNode, right: TreeNode) extends TreeNode {}

It’s OK to add methods to the trait if they would be shared by the case classes. (It would be difficult to use this tree example, because that would lead us to the field of recursive data types.)

trait NDArray {
  def rank: Int
  def isScalar = {
    rank == 0
  }
}

case class Scalar(value: Double) extends NDArray {
  def rank: Int = 0
}

case class Matrix(elems: List[Any]) extends NDArray {
  def rank: Int = {
    elems.headOption match {
      case Some(x: NDArray) => 1 + x.rank
      case None => 1
      case Some(_) => 1
    }
  }
}

Matrix(List(4)).rank // => 1
Matrix(List(Matrix(List(5)))).rank // => 2

Scalar(5).isScalar // => true
Matrix(List(4)).isScalar // => false

Avoid class level values

It’s a sign that you are about to add an unwanted dependency which will be difficult to inject/mock later. A typical usage to avoid is reading configuration values in the middle of some method.

case class BadGreeting(firstName: String, lastName: String) {
  val person = Person(firstName, lastName)
  val location = Configurator getConfigValue "greeting.location"

  def greetWith(greeting: String) = {
    greeting + ", " + person.fullName + " in " + location
  }
}

// That should be refactored to this class
case class GoodGreeting(person: Person, location: String) {
  def greetWith(greeting: String) = {
    greeting + ", " + person.fullName + " in " + location
  } 

}

Pass an argument object instead of too many arguments

The rules so far prefer explicit to implicit. It may lead to a loooong list of arguments, though. The cure for this is to create a case class for those arguments. It’s a matter of personal taste how many arguments you consider too many. I would say, don’t have more than three.