DEV Community: Lovely Developer

My two favourite (and unexpected) benefits of using Typescript

Lovely Developer — Thu, 02 Sep 2021 00:09:49 +0000

We’ve been happily using Typescript at Qualdesk (exclusively) for over a year and a half, and we’ve seen many benefits of it in our day-to-day. My vim is set up to maximise all the autosuggest opportunities and every now and then our CI errors when someone does a lazy hotfix without running it locally.

However, I’ve noticed two behaviour changes in our development team—things I haven’t seen mentioned in articles about static typing before. And for me they became the top benefits of using Typescript in our team.

Improving our conversations about solutions

As a team that depends heavily on code reviews in the form of Pull Requests, getting other people’s opinions about our solutions is second nature.

However, Pull Requests come pretty late in the process —at the time when most of the work is already done. While this doesn't stop anyone from giving their honest opinion, it can be difficult to trade off implementing feedback vs shipping the code that has already been written. Even when feedback points to an objectively better solution.

Feedback about a particular approach can be achieved earlier with a short document, a draft of a diagram or a gist with pseudo-code -these are all perfect ways to get feedback on potential solutions. The disadvantage to these is the additional time taken creating something that wouldn’t have to exist otherwise. And sometimes actual code is a better language to communicate your concept with.

With that in mind, Typescript interfaces allowed us to get this early sense check without leaving a text editor. We can start building by defining interfaces and data models —not unlike in Interface-based Programming —and use those to start the conversation about the approach. Other members of the team can more easily understand how the proposed solution will work, and can ask more targeted questions (how it interacts with the rest of the code, how it impacts our plans, etc.)

Recently one of my colleagues, Callum, used this method to ask for feedback on approach for "content bundles". This led to a conversation about specifics of the implementation, helped him clarify the idea in his head and prepare his approach for the changes that were happening in parallel. If he had to write up the solution as a document he would most probably jump straight into coding instead and wait for feedback on his Pull Request (which, I guarantee you, would conflict with the work that was happening in parallel).

Writing simpler code

In this case, rather than Typescript enabling something, this is about it stopping us from doing something bad.

Typescript makes it really difficult to write overly complex code.

No matter which direction you approach it — types first, implementation first or any other way of organising your work — if the code is complex, the types for it will be as well.

If during code review you start reading through types that are not immediately understandable, there is a high chance that the underlying implementation could be simpler.

Another thing about Typescript —it stops you from writing code that is prematurely abstracted or over-generalised. Generalised code in Typescript will either use generics or types for things that don’t exist in code yet. The former might be correct, but quite quickly gets more difficult to understand than the implementation itself. And writing types for things that haven't come up yet is not difficult— it's impossible. You very quickly conclude that you’re making things up, and you shouldn’t commit that to the repo… because you aren’t gonna need it.

These two benefits ensure I won’t be going back to vanilla JS anytime soon. They makes me consider what languages we might add to our tech stack in the future – static typing will be high on the requirement list.

I’d love to hear what you think – do you prefer the relaxed environment of dynamically typed languages or the benefits of static typing? Are there any other benefits you noticed from using Typescript? Feel free to comment or tweet me at @lukaszsagol

How to run visual sprint planning meetings

Lovely Developer — Tue, 24 Aug 2021 21:29:37 +0000

Last week Peter wrote about advantages of running a visual sprint planning. But what is visual sprint planning? And how does it work in practice? Let’s have a peek at how we, at Qualdesk, use a digital whiteboard to make our planning visual... and therefore better.

When it comes to sprint planning there is one main goal – agree what the team is working on for the next sprint. But there are different things you can optimise the process for.

You can do planning as fast as possible, so the team can spend more time building things. Or you can ensure that stories are perfectly sized, so you finish them all within the sprint.

At Qualdesk, we decided that what’s most important is enabling every team member to impact the plan, share their opinions and propose what we should be focusing on.

Using a multiplayer whiteboard is at the core of this (not only because we’re building one) because you can’t expect people to be fully engaged if all they get to do is watch someone else sharing their screen. So, putting all our work and conversation into an environment where everyone can “touch” it massively helps with encouraging people to take part.

But there is a bit more to it.

Step 1: Create a public space for sprint candidates

Before our sprint planning meeting, we put all the candidates for the next sprint onto a shared Qualdesk board. It is easy to access by everyone on the team as it is organised into a team workspace on Qualdesk, which means that anyone can put things onto the board at any point in the sprint (although, to be fair, most of the putting happens the day before the sprint planning).

Apart from regular groups of issues like “things left over from last sprint” or “bugs for next sprint”, anyone can put proposed Epics, UI improvements, questions or issues based on feedback from customers.

We put everything into Qualdesk groups, which later become the structure we use to organise our conversation. Usually, we end up with a board with following groups:

three or four groups representing different Epics with their subissues
things from last sprint
selected bugs
UI improvements
small issues from the backlog

We specifically split out the bug selection conversation from sprint planning into a separate “bug grooming” session, run by engineering team where we discuss reproducibility, potential fixes and how critical it is, afterwards deciding if that should be

This means that before we even start the sprint planning meeting, everyone has a complete picture of what we will be talking about.

Step 2: Open conversation

Time for the unstructured, organised chaos part of the process. We all join a call and go onto the board and... we discuss the groups above, one by one.

We don’t do it in any particular order – sometimes we even stop discussing a group halfway through if the conversation takes us in such direction.

Whoever added the group presents the rationale behind it, and we make a decision on whether or not to include it in the sprint based on

what we’ve already agreed should go in the sprint
what we’ve heard from customers
our longer-term priorities
the effort required to deliver a viable version of what’s in the group (this sometimes involves removing things from the group, or splitting a group into two ‘releases’)

We don’t vote, we don’t estimate, we just discuss, because at our size it’s the quickest way to reach an agreement. This is when Step 3 comes in.

Step 3: Immediate commitment (agreements as data)

As soon as we have agreement about what should happen with a group of items, we immediately change the data in the system of record (in our case, Jira). We add them to the next sprint, the sprint after, or move them back to the backlog. Sometimes we also use this time to restructure stories, change epics and assign ownership.

This saves us a huge amount of time. Instead of one person having to note down or remember what we agreed and then spend time, after the meeting, writing it up, we save those agreements as data in Jira straight away, literally with a few clicks.

Summary

This method of running sprint planning helps us achieve the goal of getting everyone involved, having their voice heard and having direct impact on what and how we build. Even though speed wasn’t our highest priority, I believe this method makes for very quick sprint planning meetings (there are quicker methods, but without similar levels of team’s involvement)

A small disclaimer: the methods we use might not work one-to-one in your case – we are a team of 5, so we can afford to do things in a less structured way. However, I hope these can inspire you to make your own meetings better too!

If you found it useful or it sparked some thoughts, don’t hesitate to tweet me @lukaszsagol. And if you are curious about how Qualdesk can make your planning meetings better sign up or get in touch for a one-to-one chat about how to run your sprint planning in visual environment.

Developers, swallow your pride and just do stuff

Lovely Developer — Fri, 09 Jun 2017 09:55:48 +0000

Doing things the wrong way to get the right result

There are many different routes you can take on your journey to becoming a developer. Mine ended up including a formal Computer Science degree, which meant learning a lot about software development philosophies. Regardless of whether you took this route or not, you probably found people telling you what is right or wrong.

Write tests.
Keep it simple.
Separate concerns.
Don’t repeat yourself.
Never use your prototypes in production.

All of these are helpful guiding principles to inform your decisions. But being a good developer is not only about following rules, it’s also about knowing when to ignore them (luckily, unlike an accountant, your creativity will rarely end up being considered embezzlement).

On one of our recent projects, we got way further by doing something “the dirty way” and ignoring our inner good developers. Before I share the specifics of that project, I’ll tell you a story of a side-project to illustrate why you should play against the rules sometimes . The fact that it includes a severed finger (just a prop!) only makes it easier to remember.

I know I’m using developers as a reference point here, but that’s only because of my experience. I’m sure that the same thing applies to other roles as well.

Don't redesign the finger

Just like any other project, this one started with a problem – albeit not a very profound one. The door entry system to our studio is bog-standard – guests buzz in on one end, and a phone with a button releases the door lock on the other. The finite quantity of entry phones (2) and their wired nature means that they can be within reach of a very limited number of people. If these people are not at their desks, someone has to stand up and walk up to the nearest phone to let our lovely guests in. As a breed known for being efficient (lazy), we knew that technology can save us.

That job doesn’t seem difficult, does it? The right way of dealing with it would be to create a piece of hardware that directly replaces an entry phone. A “connected entry phone”, with Wi-Fi connection allowing everyone to open the door from their laptops. To make it happen, we would have to:

remove the current way of interfacing with the system
understand internal protocols of the system
connect the thing
test correctness of the solution
and ensure that it doesn’t impact on the rest of the system.

Wait a minute! Internal protocols? Impact on the rest of the system? Ok, maybe the task is bigger than we thought. Not to say that these challenges are not exciting. They would definitely make for an interesting investigation, but you have to ask yourself – how long will that take? Is it worth the necessary time investment? If not, is there a way of getting to our goal faster?

We’re talking about a side-project – we want to benefit from the solution quickly. To see if it’s possible, let’s take a step back for a second. What if instead of looking “under the hood”, we look closely at what we already know and understand – the entry phone.

We know how to interact with it âœ”ï¸Ž
We know what action to take to open the door âœ”
And we know that doing so doesn’t impact on the rest of the system âœ”ï¸Ž

With that knowledge all we need to do is to press the button – and what is the best tool for pressing buttons? A finger.

This is what we ended up building. We built it without having to worry too much about the internals of door opening systems. Instead of taking a deep-dive trying to learn about all the processes and connecting at the lowest possible level, we focussed on making the difference by building on top of what we already understood. Most importantly, by doing so, we didn’t lock ourselves out of the possibility of improving it in the future. From making it nicer, if such need arises.

You don't need an API

Before you scroll to the bottom of the page to jot down how “it’s never that clear-cut on a normal project”, let me assure you, we’ve done stuff the wrong way on many projects. The very reason for writing this article, is seeing how ignoring the rules helped us build amazing products.

One example is the project I hinted at at the start of this article. We were building an employee mobile app for YayHappyFunTimesCorp (before you start googling to see what they’re about – it’s not their real name). It was at MVP stage and based on our user testing we had picked a feature that would benefit the employees the most. Next step: running a pilot in a couple of shops to validate it with real users.

The functionality we were looking at was heavily dependent on the data in YayHappyFunTimesCorp’s internal, legacy systems. In situations like this, we would aim at integrating through an API-based system-to-system communication. Unfortunately, not only were those legacy systems devoid of APIs, they were also extremely internal, to the point of not having any access to the Internet. Of course it’s not the end of the world – firewalls can be opened and APIs can be built – but unvalidated assumptions and impatient employees are waiting.

Once again, we had to take a step back. Find a “quick and dirty” solution, that allowed us to release the pilot quickly. The one we found took “quick” to the extreme – it didn’t require any code. To move data between systems, we printed it out and manually keyed it in. Manual weekly sync. We might have wasted four hours a week for six weeks on tapping on our keyboards, but we validated if we were building what users want (surprise, surprise, yes we were).

Similarly with the finger project, we made sure to not lock ourselves out from refining the solution in the future. Not only that, we actually started working on the improvements straightaway. Over a few months, we moved from print-outs to manually uploaded CSV files, then to automatic CSV imports, to then reach our final stop – API communication. All the while we continued releasing to more people, learning about how our feature was being used and what was required. The experience that we gained meant that the API structure we used in the end was very different to the one we would’ve suggested at the start of the project (This whole story was also the background to an article that our awesome developer Kat wrote about using AWS Lambda).

We started with a completely unscalable solution, which enabled us to validate the need. We then evolved it, step by step, to make it support more and more users. On the way, we learned not only about our users, but also discovered what the technology requirements were. We can only speculate what the outcome of the project would have been if we hadn’t let ourselves find a “quick and dirty” solution.

Just do it

On every project, sooner or later, the time for a decision like this will come. A decision between building something that feels good to build, and something that just does the job. Between something that takes time, and something that validates quickly.

It will impact the product. Some of them will increase technical debt. Some will work only on a small scale. Some will actually require people instead of code.

Whatever it is, don’t be afraid to close that “best practice” book and turn a blind eye to a dirty hack here and there. As long as you are aware why you’re doing it and ensure it doesn’t lead you to a dead-end, you will be fine.

And if you’re in doubt, remember...
// Detect dark theme var iframe = document.getElementById('tweet-841802094361235456-614'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=841802094361235456&theme=dark" }

Made by Many is a new type of consulting company that brings together product design, business strategy and software engineering as a unified discipline. For 10 years we’ve been helping forward-looking companies to re-imagine their customer experiences, create new models for growth and build new capabilities. See our work.

Originally published at madebymany.com.