Process

Turtles all the way down

/ timmeeuwissen / Leave a comment

A story about the risk of over-abstraction and false assumptions on technical debt.

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever,” said the old lady. “But it’s turtles all the way down!”

The first time I’ve got in contact with this story is when I read the book Godel Escher Bach. Although it seems hilarious, it also points out that there is no solution for human stubbornness and lack of logical thinking. It is an exceptional example of missed credits for the inertia of mankind’s cumulative factual cognition, or perseverance of human-induced stories one could believe in.

Not soon after, I started recognizing some of these silly patterns in my own behavior. Of course regarding personal and behavioral stuff, but it somehow concerned me more that I noticed that these patterns can easily be found in day-to-day technical tasks. A recurring theme in my software seemed to be some serious over-engineering with abstractions over abstractions, all to separate concerns wherever possible and isolating whatever could be isolated. The layers of abstraction grew so thick that they became very hard to follow for anyone else including my future me, and I realized I needed some serious re-prioritization of what I perceived as good practice in software development.

The rule of three

It is so, so hard to leave technical debt when you’ve had a history full of it. This becomes the second nature of a developer. Remove any tech-debt up-front before it bites you in the ass afterwards. But there’s a risk in this.

We tend to prematurely optimize our code. But the risk here is that we optimize without knowing the full set of features that are required. This is when I introduced the rule of three (which sometimes is ignored, sometimes the rule of two, but don’t tell anybody okay?).

Only when you’ve seen similar functional demand occur three times, start clustering the functionality and isolate the individual concerns.

By the time you’ve implemented a third similar functionality (which usually needs some adaptions to work in a specific situation), you can tell something about the environment the component should work in.

Set your KPIs

(For those who don’t know, Key Performance Indicators, the stuff that tell you if you are doing the right thing or should pivot your efforts).

This might seem strange, but make sure you set your definition of done straight before you start the development of new features. The definition should only encompass the creation of functionality. Not the how. Just the what. Don’t create elaborate structures, but try to get to your goal the fastest way possible.

Honoring:

  • transparency
    Read your code, and let someone else read it (peer reviews). If it’s not clear what it does or how it works, it’s not good enough
  • Usage of other modules (DRY (Don’t Repeat Yourself))
    Don’t do work that’s already done
  • Don’t implement features you don’t directly need (KISS, Keep It Simple, Stupid)
    I guarantee you that the functions you consider nice to have but unused, will be the first to bring your code to a grinding halt.

You’ll need these KPIs! Because odds are that you won’t feel good – at all – about the product you’ve just delivered. There’s ALWAYS a better way to do things, and that shouldn’t drag your just created real-life value down. Satisfy your KPIs and feel satisfied. But watchful.

Observe

Take notes along the path of deliverance. Mark the project as Concept and MVP (although functionally you might feel you’re there, you can sometimes treat functionalities as separated products) and keep track of it. Observe all stuff needed in the future and observe if your suspicion of lacking features, abstractions and re-usage of code are right. If so, don’t be shy to become your own PO and create a story that removes tech-debt. If your relation to your usual PO is one that has trust in it’s fundament, he should respect this story as much as any other feature request and allocate time to remove this technical debt.

Apply validated learning

By waiting to apply all these abstractions, you enable validated learning (beautifully described by Eric Riess in The Lean Startup) to more or less scientifically confirm the future of the feature (the standard definition used in validated learning), but also the need and the focus of the future optimization.

Bottom line: You’ll spend less time, on stuff that get’s thrown away.

It’s not turtles all the way down anymore. It’s just a bunch of oddly stacked turtles on a ridge in some water on a planet.

What follows after this.

I’d still like to write a blog post about testing code. This article about levels of abstractions relates to that future testing blog post in so many ways.

If you’d like me to put some focus on that, let me know by using the poll on the right side of the screen!

Work ethics, rewards and private balance

/ timmeeuwissen / Leave a comment

I have seen many different work-ethics. Some people are working day and night, neglecting their own needs as a human being (trust me, it will bite you once you get older). I’ve also seen others that show no interest in company goals and strive for tops 3 hour efficiency and well-groomed social media profiles every day.

 

I’m writing this blog post because I think that with the right argumentation people can get on-track, become more efficient for their bosses, but also in their personal lives.

Believe in the company goal

It’s paramount that you believe in the company goal, believe in the people that wish to go there, and believe in the fact that you’re going to achieve that goal. If you are not certain of one of these things, you should vocalize your concerns.

Why? Because your and your peers future success, and joy in daily work rides on it. You will never be able to work really hard for something if you don’t believe in the thing you are working for. Don’t forget that you spend more ‘conscious time’ at your job than you do anywhere else. So don’t waste that time and optimize whatever can be done to achieve the best results.

When you join a new company, you should really investigate what the goals are and if they are in line with what you feel is best and fitting with where you personally want to go.

Career opportunities

Never settle for the job you’ve got, always work for the job you want. Opportunities don’t automatically come your way. It’s hard work, and if you follow the company’s goals whilst not neglecting your own needs, you will achieve more.

Especially for people in tech willing to grow, I would suggest to force yourself every once in a while to perform in an uncomfortable setting. Speech in front of 50 people, be bold (not bald, that’s another blog post) and question your PO’s or clients about choices they make. Dress for your job. Anything. Just put in more effort than is minimally required. You will see that it’s uncomfortable at first (that’s a guarantee), but will boost your communication skills, technical skills and moral. You’ll be more visible on the radar.

You can be the best programmer on the planet and create something that somehow saves the world from climate disasters, but if you don’t evolve the skills to communicate about it, no one will know nor care about it.

By setting career goals, and being willing to fall while you stumble to get there, you’ll grow.

Once you know what you want, you should fight for it. Because if you cannot fight for your own worth, then how would you be able to fight for the same thing for your boss. You should always put your own goals in the scale with more weight than the company goals. But that said, this is not a black and white world. Try to scan the horizon for every possible way you can unite these two goals in to one, and be verbal about it to your boss before you let the scale decide. When he or she cares they will pursue the exact same path (a compromise or optimum that’s in some way beneficial to both parties). If they don’t, the environment you’re in might not be the good one for you and you should consider the weight of the problem and be strong enough to draw conclusions when needed.

Be worth what you are paid for

When you’ve been an entrepreneur, you’ll know – no, let me rephrase that – you’ll feel the real value of the money that you receive each month. Money doesn’t come for free from a magic tree. It’s a hard earned currency that you and your fellow colleagues have worked hard for. There’s no guarantees that it’s there next month or the month after. That’s the stone your boss might have on the bottom of his or her stomach. The risk they take and lay awake from at least a couple of nights in the year.

Employers don’t want to make decisions you don’t like, but they need to do it anyways, or they might draw the short straw on the vow they’ve made in the beginning of your employment: I shall provide money each month so my employees are rewarded for their efforts and their families mouths fed

When you negotiate with your employer, don’t negotiate beyond that what you are really worth. Make sure you can look them in the eye when you convince them of what you are worth and believe in your words. And again, if you can’t fight for your own (fair) salary, how can you fight for the income of the company. When you feel you’ve reached your capacity, know when to stop. You don’t want to work a year with the constant feeling that you’re being less productive than paid for. There are more ways you can be rewarded than with money. Think of growth opportunities, flexibility in location an times to work from or other ways.

When you create awareness for yourself what you cost the company, you can (and should) use that knowledge when you are working. Assess if you are worth your cost every once in a while. Good bosses do the same.

Work to live, not the other way around

Work hard, play hard is a good thing to keep in mind. Charge yourself, enjoy your life and reflect on what’s happening because time flies. Nurture your home situation with the same care and awareness that you apply on work. Strive for an equilibrium. You will only succeed in one or the other if you can find a balance. Life doesn’t work in sprints, it’s a marathon.

Bottom line

It’s all about balance, honesty and positivism. One could almost say that the term ‘self fulfilling prophecy’ is a derivative of newton’s third law:

When one body exerts a force on a second body, the second body simultaneously exerts a force equal in magnitude and opposite in direction on the first body

So find your optimum. Find peace and positivity or execute on thoughts or actions that enable you to do that. Put in a lot of effort and positive energy, and the reward will eventually be as good for a long time to come.

Tips on how to conduct a retro

/ timmeeuwissen / 2 Comments

For: scrummasters and teamleads

The most important thing with retro’s is that you have them. But when you have them, there are a couple of things that you can do to optimize and get the most out of them.

When to do the retro

Try to schedule the retro after the sprint, around the moment you do your demo. Since the team will already start looking back on two weeks and see what has happened and how they can demo their achievements, this is an ideal moment.

Use sticky notes

Let everybody write down their own positive and negative points on sticky notes. Some members may come prepared with some sticky notes that they have gathered during the sprint (if you see that there’s not enough quality feedback you can suggest doing this to the team). Each note can get a + or a – in the top.

Create a board with two or maybe three lanes. A lane for things that didn’t went so well and a lane for positive things. When someone is done, let them put their notes on the board. Each member can see if one of their points was already put on the board. If so, let them stack. Big stacks, usually indicate big concerns regarding that point.

Some benefits of doing sticky notes instead of going sequentially through all members:

  • everybody can write down their own thoughts, and don’t have to remember them through the talks of others
  • you can monitor actual participation in the retro, instead of having a ‘what he / she said’ or ‘I have nothing’ answer
  • you get to know some sense of how big a concern actually is
  • you can take the notes with you to process them later and not have everyone waiting for you

What to put on the notes

It’s important not to narrow the scope of these points. Let people tell that they’ve had a good barbecue, a nice birthday or a dog that died. Because influences from our personal lives into our professional lives, are as real as the other way around. Being able to briefly share your joy or sadness on something, makes this meeting something to look out for, and it’s an easy way to share stuff with your team and fortify your future collaboration. When a team member feels heard and seen, he’ll tend to stick around longer.

Run through the notes

Start with the points of concern. This is because of two reasons. You don’t want to spoil a good vibe, and people seem to cling on to the vibe they left a meeting with. This way, the momentum you’ve built during the discussing of positive things will carry on after the meeting. Create piles of all + and – notes

Guiding the meeting

Rotate members to read the cards (different member per retro). This trains them in speaking and conducting meetings (even though this is a very small and safe meeting), which will help them in the future. Also, you’ll prevent biassing the meetings with the tone of one person that always reads the cards.

Let someone take notes, but only on the action points. So when the team discusses the cards, only write down how they think they can do better. When the meeting is over, create a page with a retro template in Confluence (or any other tool you use). Take the stack of + cards and write them on the column ‘what we did well’. Take the stack of – cards and write them on ‘what should we have done better’, and take the notes of the discussions and put them on ‘actions’.

Revisit the list of previous action points at the end of each meeting and compare them with the list of actions from the previous time. Don’t add unsolved actions to the new action list. When an action didn’t get recurrence, it fell out of grace and might have not been a thing for an action point after all. Do ask which of the actions have been done, and update your previous actions so they get marked done. You can look over-time if actions get recurrence. This enables you to detect inefficiencies within your way of working.

DoD: Distribution of Development

/ timmeeuwissen

For: tech entrepreneurs that are considering the options on where to source their development power from

It’s not an uncommon question. Should I outsource, should I create a distributed environment or should I keep everything (literally) in-house. There comes a time in nearly every company when these options will be (re) considered.

This blog post should shed some light at some possibilities and some of their pros and cons.

The candidates

Local-only

This is when you hire from your own county.

Pros

  • One language that everybody understands
  • You can easily walk up to someone
  • Trust can be established by seeing someone at their spot
  • It’s easy to bond
  • Pair programming and doing coding dojo’s are easy to do
  • You can facilitate a nice entourage and a real sense of being part of something big

Cons

  • You’ll have to reimburse travel cost
  • Hard to find competent or top-class people
  • Because you can easily walk up to someone, you basically disturb them and a lot of effective time can go to waste
  • Being at a spot, doesn’t say you are working or doing that efficiently
  • When you find someone very competent from another country, you’ll have to relocate them

Verdict

It’s easiest to start a company with local people. You can establish a brand, have short (but probably more inefficient) communication and reporting lines and you won’t have to take cultural differences in to account. Because you will have to set-up a facilitating environment anyway, it’s also a good base on which you can start working with interns and juniors so you can really supervise and even micro-manage every now and then (you shouldn’t but we all know it happens when you are still small).

 

Outsourcing

This is where you completely carry over all development to an off-site company.

Pros

  • It’s well known that some outsourced development is cheap as pennies in some countries.
  • You can prototype and work in parallel
  • You can hire for what you need. It’s scalable in that sense.

Cons

  • You might get the features you’ve asked for, but who guarantees the quality and the longevity of the code
  • You will have to meticulously write down every possible expectation of the product you wish for. Don’t assume it will be done for you.
  • There is no intrinsic motivation or personal attachment to the quality of the product
  • You will have to overcome cultural differences and stand firm when someone that works by different rules, laws and ethics disputes your requests or assumed rights.

Verdict

I’ve tried this for a part of an application, but this backfired horribly. It’s hard to gain trust and monitor the quality. You could do this if the product is in example a tool that you just wanted as a prototype to get a better grip on your value proposition. One-time, never look back applications (e.g. apps) get developed like this all the time with good results. Working on a SaaS? Don’t do it, I would say.

 

Truly Distributed

The address is a formality, this is when there is no such thing as an office. Lots of pros and cons on working distributed have been mentioned above, so I’ll try to limit the pros and cons to only that what’s important and different if you work truly distributed

Pros

  • There’s no overhead of physical buildings involved. This money can go directly in your company and its employees
  • you will start judging people on their performance. “Did they do the thing I asked of them” will be more relevant than, “did he work 6 hours or 8, and did he work in the morning or evening”.  This actually ties more in to the nature of people. Attendance is something less relevant than focus.
  • You can work from EVERYWHERE. This is true for the developer, but also for the entrepreneur. Want to travel the world, but still get payed? This is the company to join!

Cons

  • depending on how big the range of time difference is, it can be truly a madhouse to orchestrate everybody in to one virtual room.
  • it’s harder to bond with the team.
  • it’s harder to create a hierarchy or other form of ladder on which the developer can grow. Personal growth must be attended to, it is one of the prime concerns of any developer

Verdict

I have seen and heard companies succeed in this setup. It brings its set of challenges but also benefits. I think that going truly distributed is not something for the fainthearted.  Especially the entrepreneur will have to be the link between all developers. Every part of the process has to be looked at, cleaned, oiled and put back in. Is the documentation there. Is it in proper language. Are all code standards applied. Did he communicate nicely to his peers. etc etc. These are normally things you pass on to your leads and managers, but (especially when you start) should be done by the owner to ensure his company still sails the charted course. I would say that it’s not a natural first choice. You have to have the experience, and maybe it’s easiest to come there by progressively hire more external and bleed out local.

 

Externally integrated

This is when you have the majority of your employees locally, but you also hire dedicated people abroad.

Pros

  • dedicated workers for your company mean they (could or should) feel in line with the company’s goals
  • working with different cultures really broadens your horizon. You’ll become more creative in work and this will reflect to your personal lives. It’s an absolute joy.
  • no cost of commute
  • having this division, enables you to not have all your eggs in one basket. (e.g. internet goes down at HQ, or everybody resents recent management changes and strike or find different jobs)
  • When you hire through an agency, you are able to scale your external development faster.
  • The infrastructure that you should get in place (think of cameras, digital boards, good documentation, communication pipelines etc) is also beneficial for your on-site employees. All of the sudden they can also efficiently work from home
  • All communication should be in a language that everyone understands (most common is English). This future-proofs all documentation, code, etc and prepares your company for being true to serving the World Wide Web (distribute for everyone to read, all over the world).
  • You still have a place to go to, a brand that can be visited

Cons

  • once per X time you will have to gather, take the plane and meet each other for some time and do bonding. This is an expensive undertaking. I have heard from someone who actually has a fully distributed team that the cost is generically about the same as the cost of commute for local people (for a mid-sized company hiring in the same country).
  • Initial setup can be demanding on people and budget.
  • You will have to oblige to the law from wherever you hire. Some laws are really strict and can discourage experimenting with this way of working.

Verdict

When you have the time and means to orchestrate this, I’d most definitely do this. It’s a perfect hybrid form that – even if it fails to work remotely – also greatly benefits your local team.

This will only succeed if you will have someone on the other side willing to understand and work with your company. Be critical about who to hire, especially the first one. But this will also only work if people on the local side bring this person in to all relevant discussions and support whenever this is needed.

Having the mindset and the infrastructure in place, you also create a nice environment for your local employees. They can work from home whenever needed, you remove ‘knowledge lock-ins’ in your team and individual and team performance will go up.

Offshore

(in different time zones)

Extra pros

  • able to run support and development 24/7
  • the world truly is a bigger place than a specific timezone

Extra cons

  • It becomes increasingly harder to communicate when someone lives further
    • daily routines
    • planning deadlines
    • evaluations
    • establishing unity within the company

Nearshore

(in the same timezone)

Extra pros

  • Time of communicating is no issue
  • The locations are generally ‘near’, so cost and time of traveling every once in a while shouldn’t become the main reason to do or not to do it

 

Conclusion

So you’ve probably read it well. The definition of how it’s properly done (DoD), resides in the distribution of development. It might not be low hanging fruit, but the stuff that hangs higher get’s more sun you know ;-). Striving for it might already make the difference. It’s up to you to decide how to implement it for your scenario.