Manfred Touron
☰
✕

Why I Trash V1 of My Projects (And So Should You)

Photo by Steve Johnson

Introduction

Do you code a lot? I do. Over the years I’ve written and open-sourced a lot of projects, many of which you can see here.

I’ve also worked on several important projects in companies, bootstrapped startups and other team-based projects, and audited several startups.

Now, a lot of the code I wrote felt right while I typed it – you probably feel the same way when you code. But then later, when I reviewed it, I found plenty of hiccups and gaps in it. And there was also a lot of code that could be polished.

No wonder then that at the end of almost all my early projects, I had to rewrite most of the code. Version 1 (V1) code didn’t really make it into the final product. It had to go out.

The Problem: Or How I Came Up with the “Trash V1” Rule

The fear of trashing code is certainly the number one reason for the technical debt. However, when you split your code you have way more chances to fail than to succeed.

Often, it’s tempting to spend a lot of time on a piece of code to “make it perfect”. But when you start a project, it’s hard to define perfection in a piece of code. You need the insight that only comes after you finish a version of the code to figure out what would make your code perfect.

If you try to make your code perfect from the start you know what will happen? It will be twice harder for you to trash it even if it’s faulty or just useless, for the simple reason that you’ve invested in it a lot of energy and passion.

I’ve been through all that. Most of my V1 code that I kept back in the early days was just regrets. Usually, I ended up rewriting everything, losing not just time, but adding more retro-compatibility constraints to the code.

You should never do that.

The “Trash the V1” Rule

Here’s where my rule comes in. It’s a simple rule. It consists of assuming that “nobody (not even me) knows exactly how we want to do the project.” Or, to put it in a different way, that not everybody is aligned with the final expectations for the project.

This rule is essentially an extra step that costs you only a few hours or days but that gives you an extra guarantee. The guarantee that you’ll be able to find the right code when following your roadmap.

At the same time, it’s also a good way to check if the project is interesting. You can consider it as a “trial period” during which you familiarize yourself with the project and understand it thoroughly.

Set this simple rule before you start coding. If you have a team, you should announce it to them before you get to work. This way, you ensure that nobody will lose time on an over-engineered, over-optimized piece of code that in the end fails to deliver the expected results.

Here’s a tip to make sure this rule really works for you: set a short time limit, let’s say 1 evening for a solo project or 2 days for a team project. For bigger projects, up to 1 week should be okay too, but the shorter the term, the better.

And here’s another tip: at the end of the proof-of-concept phase (PoC), even if the project is not yet finished, focus on the core value, on what makes it unique and better than the competition. There’s a chance that your project is already on its way to being “the best piece of software to achieve that thing” in the world.

Now, let’s take a step-by-step approach to implementing this rule. Follow these steps for best results, and to speed up your project too.

How to Implement the “Trash the V1” Rule

In the beginning, the most important thing is to stop trying to define all the specifications of what is yet an abstract project. Make the project as concrete as possible by focusing on what you know about it and only then define the missing specifications.

Step 1

Focus on what makes the project unique and write the core specifications. So, what’s special about it? It can be an original feature or a significant difference compared to an existing solution.

Step 2

Explain the rules to your teammates. Choose any additional constraint (time limit, framework/library/method to use) that can help keep you all focused.

Step 3

Remind your teammates that everyone should avoid doing early-optimizations and over-engineering.

Step 4

Code. Do it quickly, with the aim of creating a working version of the product. Don’t waste time on it.

Step 5

Trash this code. Yes, trash it. Actually, you can just archive the repository in read-only mode and consider manually copying some parts later. It brings you some peace of mind.

Now, you have something concrete and you can write better specifications and a more accurate plan. Technically speaking, you are also able to demo your idea to your coworkers, family, friends, or investors.

Step 6

Start a new codebase and write the V2 of the code. Ideally, this version should be the one you publicly release.

Conclusion

I use the “Trash V1” rule for every big or difficult project I undertake. I use it for personal projects as well as for team projects. Even if this rule seems more appropriate for project bootstrapping, it can also be applied to subparts or experiments in a later phase of the project.

Do you fear trashing code? You shouldn’t. Letting go of code you’ve written may not be easy but it’s beneficial.

If you overcome this fear and apply this rule, you’ll actually save time in the long run. In many cases, “Trash V1” will enable you to skip the first required rewrite that usually happens 6 months or 1 year into the life of the code.

So, make this rule a habit – trash version 1 of your code. It may be a bit scary at first, but you won’t regret it.

Automate ArchiveBox with Google Spreadsheet to Backup your internet

Introduction

I just discovered ArchiveBox on my GitHub feed.

ArchiveBox allows you to store copies of webpages at a specific time.

It is still new for me, but from what I see, my workflow will be something like this:

  • to store copies of interesting webpages that I may want to read again later, i.e., my bookmarks; and then, use these archives:
    • as a backup link when the main page is outdated
    • as a way of comparing how the webpage would have changed with time (diff)
    • to list my interesting links
  • to periodically monitor changes of webpages I want to follow over time, i.e., my public social profiles, or this site web

To make it easier for me to maintain, I want to update a Google Spreadsheet and never touch a shell anymore.

My setup

First, write some links on a Google Spreadsheet document.

Then, publish the document in CSV format.

And finally create a script that will fetch the links in CSV and run the archiver against those URLs.

Here is my custom Makefile:

And my adapted docker-compose.yml file:

Run make loop in a tmux or another process-backgrounding method.

Result

I now only need to add new links to a Google Spreadsheet and let my script do the rest.

Windows 10 Setup 🖥

Image made with Paint.exe

Introduction

I recently ordered a Microsoft Surface Book 2 with Windows 10. The last time I used a Windows for something else than playing games was in 2006.

About the “why”, here are some reasons:

  • to give a new trial, especially after seeing Microsoft becoming more and more “cool” company, in the Open-Source and Linux world,
  • to get out of my routine/comfort zone,
  • to be able to see how my different projects are running and are easily usable by a developer under Windows,
  • to put the same shoes that people I will try to help with my apps and projects,
  • for the challenge of having a very secure Windows configuration,
  • to have arguments if I need again to say that I don’t fit with Windows :)

I wrote this blog post while installing to try to be exhaustive. I hope this article can be useful for someone else trying to switch from Mac OS X to Windows, or for people interested in running Windows from a Security/Developer/Musician guy’s point-of-view.

(At least, it will be helpful for me for the next time I need to install a Windows machine.)

Windows Install

  • Disable anti-privacy options
  • Disable Cortona
  • Enable FaceID
  • Use a strong password for the pin, not a short number
  • Device encryption is now the default, well done Microsoft 👍
  • When the install is done, reboot, log in, and let Windows download and install all the updates (multiple reboots)

Apps & Settings

Not yet installed/tried

  • Affinity Designer or equivalent
  • Something that synchronizes screenshots in a Cloud Folder
  • Cinema 4D
  • Traktor
  • Lantern
  • Luxafor
  • OpenVPN / Shimo alternative
  • A good weather app, with rain notifications
  • FullContact
  • Airplay client
  • Steam
  • Mailplane
  • Notes.app
  • Encfs
  • Brain FM
  • Reason
  • Pixelmator
  • Inet
  • Kaleidoscope
  • Webex

Problems & Missing stuffs

  • Keyboard binding is hardcore
  • The default Trackpad is bad
  • Using an Apple Trackpad in Bluetooth is worst
    • even with custom driver
  • The Update system is annoying
  • The Driver system is complicated
  • I miss Quick Look
  • I miss Alfred.app
  • I miss the tree view mode of the Finder
  • I miss iTerm (I tried multiple alternatives, the best fit for now is the terminal built-in Visual Studio Code)
  • I miss Mailplane.app
  • I miss iMessages and other synchronicity applications with my iPhone
  • I miss the Screenshots keyboard shortcuts
  • I miss Notes.app

Good surprises

  • WSL is wonderful
    • but slow, with strange linking between the Windows filesystem and Linux
  • Paint 3D is fun (and sometimes useful)
  • Microsoft SongSmith is brilliant

Further Readings

How I Audit Startups 🚀👀

Introduction

In ages past (from 2007 to 2011), I performed startups security audits (penetration testing, offensive / defensive security, etc). Since 2015, I perform more general audits and audited more than 30 startups. A big part of my experience is due to do previous audits :) The more auditing I do, the better I’m at it; I hope to continue doing audits regularly and improve further. In this article, I will share this personal experience.

My domains of expertise are:

  • Scaling teams from less than 10 people to more than 100
  • Scaling apps and hostings
  • Improving the developers’ efficiency with processes and tools
  • Avoiding common and less common mistakes
  • Identifying weaknesses and set up plans to keep them under control
  • Identifying recruitment needs
  • Helping to set up tech/human strategies
  • Giving a list of pieces of advice and coach the founders
  • Helping set up better communication between tech/non-tech, especially when the founders are non-tech
  • Identifying the current employees’ strengths/weaknesses and help them take a fitting role

I’m focused on looking for red/orange/green flags about:

  • Maturity and scalability of the organization
  • The intrinsic value of the technology
  • Pieces of advice & recommendations about actions to take quickly

Who asks me for audits

  • Venture capital financing companies that request “due diligence” before a money raise:
    • When the investment is huge, over 10 million
    • When VCs have specific uncertainties (though it’s rare)
    • When the topic is ultra-competitive
    • When the technical challenges are important
    • When they want me to coach the founders
  • Startups that have one or more topics to address
  • Previously audited startups that want a follow-up check or have changed enough to have a new range of topics. The most common case is a startup I audited when there were less than 10 people and that grew to have over 50 people; now they’ve got new problems to address.

My services aren’t listed on any website, I only audit startups based on my reputation from previously audited ones (“word of mouth”).

The process

Before starting the audit, I ask the founders to prepare some documents. They will be the base for discussion during the audit, but they are also documents that should always be maintained up to date, as they can easily become the best documentation for new hires, to present their company to new VCs and so on.

Points that should be in the documents:

  • Platform description (list of functionalities, list of apps, list of services, list of websites, list of processes)
  • Development history (the beginning, big refactors, big changes, big milestones)
  • Development of current tasks + future roadmap
  • Organization history (at least in the tech team): (hires, fires, leaves, current hierarchy)
  • Organization future plan (recruitments, role changes, hierarchy changes)
  • External dependencies: SaaS, tools, vendors, etc
  • Some metrics (users, activities, load, database sizes etc)

The most common format of auditing is 1 day in the office. I start the audit with the founders, speak about history, strategy, roadmap, identified strengths, weaknesses, areas of uncertainties. I conduct interviews and do the digging on specific identified topics. In the process, I enumerate some general/standard points, and, finally, debrief the founders.

Another format is ½ day by phone/video with the founders and at least 1 tech lead. We focus on fewer topics; this can work when the VCs have already identified the potential dangers.

Sometimes, depending on the context and constraints, I utilize other formats: 2 days in the office, 3 days in the office, ½ day in the office + ½ day by phone.

The deliverables

During the whole audit, I provide advice to the founders.

After the audit, I send a report to both the founders and the VCs, debrief the VCs, and do some follow-up if needed. This report can also be useful for a new VC round later (and I can debrief it by phone to the new VCs if needed). The report contains:

  • A list of red flags to prioritize in the roadmap or be the reasons for a small pivot
  • Orange flags that should be prioritized or kept under the radar
  • Green flags that should stay competitive advantages
  • Pieces of advice & suggestions

I plan to write more on this topic, to share some trends and findings I discovered.

`assh` - Advanced SSH Config 🤓

assh, formerly known as “Advanced SSH config”, is a smart tool that was designed to wrap tightly around your SSH and enhance it, like a superhero suit that has various gadgets installed. It adds regex, aliases, gateways, dynamic hostnames, graphviz, notifications, json output and yaml configuration.

Some of its configuration features are:

  • regex support
  • aliases -> gate.domain.tld
  • includes: split configuration in multiple files
  • gateways -> transparent ssh connection chaining
  • inheritance: make hosts inherits from host hosts or templates
  • variable expansion: resolve variables from the environment
  • desktop notifications: based on events
  • Graphviz representation of the hosts

assh manages your ~/.ssh/config file, taking care of keeping its backup.

lib-ssh wraps assh as a ProxyCommand, which means that it works seamlessly with ssh, scp, rsync, git, and Desktop applications depending on lib-ssh or ssh (i.e., Tower, Atom.io, SSH Tunnel Manager).

A few usage examples:

  • assh config build: Rewrites and replaces the existing ~/.ssh/config file.
  • assh config graphviz: Generate a graphviz graph of the hosts
  • assh sockets list: List active control sockets.
  • assh sockets master: Create a master control sockets.
  • assh ping: Send packets to the SSH server and display stats.

Those are some of the highlights of assh. Visit its GitHub page to find out more about its configuration, usage and integration.