Forem: Bismuth Labs

Triathlon training ≈ Startup life

Francois Stephany — Thu, 29 Aug 2019 13:35:59 +0000

I've completed my first triathlon last week and it struck me how similar the journey to the race was to what I'm experiencing in the creation of Bismuth.

Starting Point

When you're not an accomplished athlete, signing up for a triathlon is not something you do lightly. I was an avid runner in 2012-2015 but have stopped training since then. I regularly commute by bike (~9km each way) so my legs were still in shape but I've hardly done more than a 20km trip in my life.

When a friend asked me to join a small group of wannabe triathletes training for La Gileppe Trophy Orbea it was hard to resist. We would not train for nothing: we had a well-identified goal. This is very different than just aiming for an abstract objective (being a triathlete).

The same goes for a startup. Aiming for startup life should not be a goal in itself. You should have a more concrete plan.

Team & Network

The social aspect of the endeavour should not be underestimated. We were a group of five guys training for three sports. We were scattered throughout the region (Mons-Brussels-Liège, Belgium) and had only a few trainings together. It made little sense to meet for a one-hour run/swim when you live 2 hours away from each other. We had a couple of longer bike trainings on Sundays though.

But not training together did not mean that there was no network effect. Strava logs and a Facebook group conversation are powerful motivation tools. We could greet ourselves when completing an early morning swim session or a late bike ride. The odds that I took my bike for a spin after a long day were a lot greater than if I was alone. It's way too easy to postpone a task when you are the only one in town.

Humor and camaraderie work well when you are in doubt and think that you're falling behind. Sharing content and training tricks maintained the interest and made sure we learnt faster.

The same goes for a startup team. Being alone is good when you need to be focused on the work but interactions and discussions are important for ideation, motivation and mental health.

Planning

Even though we registered for a short distance (triathlon sprint), one of us showed up with an ambitious training plan. It looked a bit too much for me. I knew from the start that I would not be able to follow.

And it's alright. Sticking to a training plan you know you cannot follow is a stupid idea. Tune it down until you're confident you can make it.

On my side, I hadn't swam for ages and could barely cross the pool without losing my breath. Bike was ok-ish thanks to my commute but longer distances were an unknown territory. Running was my strongest point as I had trail running experience and knew the sensation in the legs and in my brain throughout the effort.

Knowing this, I created a plan custom tailored for me. I still don't know if it was optimal. It probably wasn't but it got me through the race without any hiccups so I consider it a win.

Execution and unplanned changes

Having the plan is only the beginning. This is something you cannot delegate, you're the one in charge. Here again, the peer pressure of the group is important. You are not accountable to them but you don't want to be the lazy ass that does not do anything.

Beware though. I've quickly noticed that social life can make it challenging to follow the plan. Up for a beer and pizza tonight? kind of text will challenge your focus and dedication. There's a balance between turning into a social hermit and going out every night. Keeping the pizza but swapping the beer for sparkling water is the kind of compromise I was willing to make.

A recent interview of Katie Arnold showed that with a bit of creativity, you can mix a social life with kids and strong long distance training.

At my level, the plan is just a guideline. The goal was not to finish in the top 10, so flexibility was more important than performance. In a startup though, you might aim for more. This is okay but be aware of the impacts on your life.

Polyglot

Triathlon or how to be mediocre at three sports

Swim, bike and run are different disciplines. Being at least decent in the three of them is the whole game. For me, it was a revelation: it is much more fun to train for three sports than focus on one.

In a startup, founders are usually doing a bit of everything. They need to juggle between sales, code, marketing, raising money and more. The result should be a balance between these tasks. Of course, the balance is different at every stage and the founder must quickly react to a new situation.

This diversity is extremely challenging but also super fun and rewarding.

Learning & staying humble

Starting a new endeavor is always full of lessons. In triathlon training, you learn to listen to your body. You experiment. You learn how you can improve efficiency by adjusting your swimming strokes. You listen to advice (try your wetsuit in open water before race day!). Some are valid in a context but not in another. Keep them in mind though, they could be useful one day.

You're the beginner with no experience. With practice, you will build confidence and find your rythm. Be patient but don't be passive.

Knowing when to slow down

In the second month of training, a pain in my knee started to develop. I slowed down training and quickly identified that the pain came from running. When cross-training it can be hard to identify a single source of trouble but in my case it was easy: my running shoes had more than 1000km. Fortunately, summer sales are always good to buy new shoes and the problem went away as fast as it appeared.

Not taking the time to slow down and identify the issue could have dramatic consequences. The same goes for a startup. You should always listen to your feelings (and to metrics) and adjust properly.

Equipment is not that important

Some would believe that you need top-notch equipment to complete a race. This is far from true and the only two technical pieces of equipment you need is a swimming wetsuit and a bike.

The bike is by far the most expensive thing you'll need. The best bike to start with is the one you already have. A woman finished the triathlon on a foldable Brompton and a lot of riders had mountain bikes. Find a cheap second hand bike on craigslist and start riding.

Nowadays, most startups can be launched without any specific equipment. A laptop and a phone are all you need to get started. You don't need a $3000+ Macbook Pro or an expensive SAP license to get started. Be smart about it and gear up only when you need to.

Be hungry for more

This is just the beginning of my triathlon journey. The sprint distance was a nice start but in the end of the race I still had some energy left. This means that training was good enough and that my body and mind were ready. The whole race was fun and a lot of endorphin was released that day. It's time to plan the next one. I'm tempted to go for a longer distance this time.

I've started to work full time on Bismuth at around the same time that I started to train for the triathlon. Focusing on both is a challenge and some will say that having two parallel activities both requiring a lot of grit is the best way to waste it. I don't believe it is. On the contrary, I think the two are complementary.

On bad days for Bismuth going for a run is a great way to let off some steam. On the other side, an early-swim session is a great way to start the day and is a good reason to jump out of the bed.

I can't wait to see how these two will eventually end up!

(pictures by Caroline Vermeulen and Lindsay Eeckhaudt)

Our Tech Stack: Rust, Typescript, React & Swift

Francois Stephany — Wed, 17 Jul 2019 14:58:13 +0000

tl;dr

Rust (actix-web, Diesel)
Swift (SwiftPM, swift-ast)
Typescript
React (Atlaskit, Redux)
AWS (Fargate, PostgreSQL RDS)
Terraform

Company Culture

I have a confession to make: I love discussing about tech stacks. They convey values and can tell a lot about company culture and the technical history of a technology team.

Of course they don't always tell the whole story: I know a place that emphasises on employee happiness and where COBOL is still king.

The holy stack that will solve all your problems does not exist. There is no silver bullet, remember? Instead, you pick the stack that makes the more sense to you, the one you're comfortable with, the one that fits your use case.

It might be tempting to go all-in in the latest technologies and niche languages. When I was at the beginning of my career someone wise told me that a new venture should not have more than one new shiny thing in its stack. I believe this is true and that developers are sometimes too attracted to technologies that won't survive the next winter.

Bismuth

Bismuth is a service that takes your code, passes it through the mill and shows you where its structure is not ideal. We are still in the early stage and have hundreds of ideas but the end goal is to improve the process of developing software. Not only for developers but also for other stakeholders.

We currently focus on mobile apps but the tools and philosophy can be applied to anything.

The Tech Stack

Bismuth has four main components:

Parsers for languages we support,
REST endpoints for API,
Workers that process the influx of code,
Visualisations engine for user interaction.

Parsers

Parsing source code can be challenging but it's an already solved exercise. Our motto there was not to reinvent the wheel for each programming language and don't roll our own parser. Each environment has its own set of tools that work for them. We probably won't be smarter than them anytime soon.

For Swift, we use swift-ast, which happen to be written in Swift. There were other options like using the C++ Swift compiler frontend but our team was mostly familiar with Swift and the library provided everything we needed.

For Java and Kotlin, we will probably go with Jetbrains UAST in Kotlin.

For Javascript and Typescript there are more options: Esprima (JS), RESSA (Rust), and the Typescript compiler itself.

API Endpoints & Workers

We chose Rust. That might sound surprising for a web API: dynamic languages have a good reputation for this type of work but Rust encompasses values that we believe in:

Correctness: Rust has a strong tendency to make you do things the right way. Is it very rare that a Rust library reaches the 1.0 version without being really production-ready.
Stability: The Rust team is very careful not to break things between releases. That does not mean that they are not moving fast (~6 weeks between releases)
Speed: this is less important for us but Rust is quite fast, even compared with C++ or C.
Libraries & build: There are tons of libraries ready to be used in the crates.io ecosystem. The build tool cargo feels familiar if you've used Ruby Gems, PHP Composer or Gradle dependencies.
All those values reflect in the community. It is helpful, inclusive and newbies are taken care of.

While still being relatively young, Rust ticks a lot of boxes. Software is hard and having a language that promotes good practice feels like a friend holding your hand.

It usually takes us a bit longer to write Rust code than to hack a Ruby or JS script but the feeling Rust gives when the code compiles is that it will be correct and that it will stands the test of time. Personally, this is a feeling I hadn't had since my OCaml days.

We believe that using Rust is also a strength when hiring new developers. Rust developers are usually sensitive to clean code: their brain has been washed by explicit error handling and a very strict compiler.

They might be much harder to find than Java developers but this can be seen as a strength as the odds to attract good developers is probably higher with Rust than Java (flame war fuel here).

UI and Visualisation

Typescript/React/Redux is now one of the standard stacks in frontend those days. Unless 4-5 years ago when the JS frontend war was fierce with a new competitor every week, we believe the winners have emerged and that we won't see too much disruption in the few coming years (i.e., React, Angular and Vue.js have won).

Our visualisations are built with D3, the de-facto standard for displaying visual data on the web and our GUI is built with Atlaskit.

We use this frontend stack both on the web and on our electron app. Electron can be really frustrating to work with at times but it is becoming ubiquitous on the desktop front (if God exists, she will destroy humanity when she sees how we waste our RAM).

Infrastructure

All this code sits into one monorepo. This is useful to keep track of everything in one place. On the negative side, it makes CI a bit harder as you have to detect which part of the app was affected. This might be alleviated by using Bazel to build every components of our systems but we are not there yet.

We deploy on AWS using Terraform. We had no experience either with AWS or Terraform but the documentation is good enough and it is quite easy to find support. Who doesn't have someone who knows AWS in their circle these days?

We use RabbitMQ for messaging between all our components. We're very far from reaching its limit and it serves us well so far.

Future

We don't know yet how the future will look like but we believe our stack is solid enough to withstand it. Time will tell ;)

Lost in translation - cooperation with technical people

Kjell Clarysse — Tue, 09 Jul 2019 13:22:03 +0000

Several years ago, I was running a humble adtech company. As a non-technical founder, I was quickly facing my limits in managing the dev process. I wanted it all of course: not expensive, fast and great quality; the impossible triangle. The technical people I worked with somehow seemed to have enough confidence to promise it all and what followed is predictable.

First issues and finger-pointing

The first issues started with quality. A lot of users and a lot of bugs. If you have 100 users and 10% experience bugs, you’ll have 10 conversations to maintain. If you have several 1000’s of users… When the market buys and the users use, you have a good reason to be confident about your business model. The frustration of not being able to deliver accordingly grows quickly.

I pointed fingers at ‘incompetent’ devs. They pointed fingers at every person who had been working on the code before them and left it like a spaghetti plate. I understood them. I had been a cheap-skate at the offset to first validate the business model and it is normal that you can get away with this only temporarily. You can guess what happened; a re-write. This time it was a costly one. Not just costly when agreeing on the cooperation, but even more costly when fully delivered because of several surprises in the dev process. I remember being happy with the result but being shocked by how rigid/expensive the new thing was to change. We finally had something nice, but we were kind of stuck with it for a while now. In a fast-changing context, especially as a startup, you want to be able to A/B test, to pivot, to try out this and that, but if your code does not allow you to, your competitive advantage of being small and flexible kind of disappears. That change would be so important, was not something that I had mentioned explicitly to the devs.

A lesson in communication

For a long time, my simple conclusion was that good devs are scarce. That’s a claim you will hear from many non-technical managers. Luckily, the company survived the difficult encounter between tech and non-tech, and I like sharing this experience to help others being quicker in identifying and cutting short issues like the ones I had. After all, the real lesson was not that good devs are hard to find as much as it was a lesson in communication.

On my side, I was judging an outcome of a process that I did not understand. The issue was to be found within that process of course. What was I expecting in the short run and in the long run? Did I really communicate that well? Did I even question myself enough on it? Did I sufficiently made clear that quick pivots, A/B testing, etc.. would be a must? Did I make a realistic request in the sense that a good MVP was more useful than a buggy full-feature? If I am honest with myself, then I have to confess a good portion of naivety on my end. I simply did not know what to ask for or how to express it because I did not know which trade-offs are at play at the dev side. I didn’t know that flexibility and architecture are linked for example. And that is just one example.

On the dev side, some elements are worth mentioning as well though. I was given what I asked. I was never questioned on what I did not ask. I did not ask for well-structured code or compliance in naming conventions or anything like that. I asked a result that should work starting from a certain day in time. I was never really confronted with the trade-off between flexibility/quality, price and time. I simply didn’t know it existed or mattered. Software architecture and the meaning of code quality were too far from my world. My lack of interest for the job of the developer was probably my biggest mistake and I think it was the developers’ biggest mistake to not have much interest for the true needs of my company in short ànd mid-term.

Genuine mutual interest

One can expect a founder to not be naïve as one can expect a developer to know how to deliver. But in many cases, both are working based upon assumptions; the assumption that you know what the other wants or needs without genuine interest in each other’s challenges. If I asked for quick and cheap, I did not know how that would come back at me and how expensive the cost of change would be.

I did get everything delivered my way at first: fast, ready to use and inexpensive. And I paid it heavily with the never-ending refactoring. This refactoring comes not only with a financial cost but also with time; valuable time if you are learning fast and not able to steer quickly. It paralyzes your ambitions as a founder. And it paralyzes your entire team if you depend on unpredictable delivery cycles. If I had known that code quality and software architecture determine your code’s tolerance to change, I would have made that a KPI.

For a long time, I thought my naivety was mostly to do with the fact that I started my business while graduating and not having worked in bigger companies yet. However, in the last couple of years I was a business coach for more than 70 startup companies at incubator Start it @KBC in Belgium and I was surprised to see that people with +20 years of career experience make the same mistakes more than often. I recently met a successful serial entrepreneur who was clearly opinionated about the topic and said “Oh, I have had big fights with all my CTO’s”. It turns out that even many established companies and enterprises have poor understanding between technical staff and non-technical management.

Conclusion

To conclude, when you are non-technical and you expect a good cooperation with technical people, you need to have a genuine interest in how they will go about it and you should only work with people who have genuine interest in what you really need, not just in what you think you need. You want to know the challenges and the trade-offs a dev team is facing. What is the goal of the code? A quick MVP to test the market or a full version that needs 2, 3, maybe 4 years of product lifetime? How much will flexibility cost and what is your definition of flexible? Which KPI’s will you use to quantify and evaluate expectations? Are these KPI’s indeed telling you the essence of what you are doing and are you sure that some of them are not vanity metrics? Which tools will you use to track, manage and improve?

I am writing this as a founder of bismuthlabs.io. For existing code, Bismuth tells companies what is worth fixing. For new code Bismuth safeguards architectural compliance, hence protecting the code’s tolerance to change. The goal is to have more tolerance to change, leading to less refactoring, better refactoring where necessary and more predictable delivery cycles. As an interesting by-product some companies look at us for junior training.
Needless to say from the above that when I met my cofounders, I immediately understood the value of the customer pain they are addressing.

How is your cooperation tech – non-tech going? Similar misunderstandings going on? Did I indicate the right spots to pay attention to? Interested to learn from other experiences.