*****************        Hey! Welcome to the Kwoosh Workshop
     *******************       -----------------------------------
    *******  *****  *****
   ********  ****  *******     This is where we talk about the things
  *********  ***  *********    we're working on.
 **********  **  ***********
***********     *************  Most things start as messy ideas before
 **********  **  ***********   they get polished into finished features.
  *********  ***  *********
   ********  ****  *******     This is a place for messy ideas.
    *******  *****  *****
     *******************       For the completed product see kwoosh.com


Low on bandwidth

Our post schedule got derailed over the past few weeks. It’s that time of year where side projects get thrown to the sidelines because of the holidays. Instead of sitting down to write for an hour; you’re seeing family, putting up Christmas decorations and ice skating at the local mall.

These are all contributing factors, but putting aside a slightly bruised coccyx, we got derailed for a lack of mental bandwidth.

This post is my attempt to get back on schedule.

Each day you’re given a certain amount of creative bandwidth. Once the allotment is depleted, you can either stop or push on, stealing from tomorrow’s supply.

Low on bandwidth - creative bandwidth vs the time of the day

Grinding on is sometimes the right choice, but it’s unsustainable. You can handle a day or two, but if you push too hard for too long you’ll burnout entirely. Recovery from the burnout then requires an undetermined amount of time to recharge and pay back your debt.

Recently, I’ve had a lot on my mind, draining my creativity before my first cup of coffee. What was on my mind? Packing and preparing for a move to Japan, preparing for a presentation at the Houston Tech meetup, Thanksgiving plans, and enjoying some last-minute travel while I’m in Texas.

I knew that with all of this happening, choosing to grind on would quickly lead to burnout. Most of the pressing issues would pass in a few weeks and then my mind would be clear to focus. After work I didn’t want to write, I just wanted to veg on the couch and watch YouTube.

After my talk I started sleeping better. Less weighing on my mind. Now with my house packed and on a boat to Japan my mental bandwidth bottleneck finally cleared. I felt like I could write again.

Sometimes we must push ourselves to in order to keep our schedules. Other times we must recognize when pushing does more harm than good and force ourselves to stop for the day or week.

When the bottleneck clears we’ll be able to eagerly pick back up where we left off. Refreshed and ready to go.

—jvd ~~~~~~~~~~~~~~~~~~~~

Numbers are dangerous

If a tree falls in the forest and nobody is there, does it make a sound? If a tweet is sent and nobody can see the number of likes was it still worthwhile?

When people launch new products, they often focus on vanity metrics: How many eyeballs do we have? How many followers do we have? What’s our Klout score? They desire to quantify every interaction.

Part of this is the human desire to seek rewards. The hit of dopamine given for our effort. The bigger the metrics the bigger the hit, and greater the urge to do it again. We soon however get into a cycle of complacency. 10 ‘likes’ is no longer enough, then 20, then 50. Your post was worthless if you didn’t get 100 ‘likes’.

I’m guilty of this myself. When I publish a new article I spend the next few hours desperately refreshing the stats page. 1 like… 5 likes… 10 likes… I had 20 likes by this point on my last post… What a waste of my time…

I’m no longer happy with just the process of creating. I now focus my happiness on a number that the product designers probably added with little thought. I serve at the pleasure of the metrics.

Did anyone ever bother to stop and think how displaying these numbers would affect the way that people use a service? What would a world look like without vanity metrics? Would I still get the satisfaction if I didn’t know how many people liked it?

Imagine for a moment if Twitter didn’t plaster its UI with counts. No number of followers. No number of retweets. No like count. Nothing.

If you didn’t know 15k other people retweeted something in your feed — how would this affect your behavior? Do the number of retweets signify influence and your perception of the tweet’s trustworthiness? Would you still retweet it?

Is it more difficult to tweet and get started with Twitter when you see that you have 0 followers, 0 retweets, and 0 likes every time you tweet?

Would you post a different picture if you weren’t trying to get the most likes? Would you tell a different story? Would you still check-in at the airport?

What if you could see your numbers, but you couldn’t see anyone else’s numbers? You could see you have 100 followers but not that @tomhanks has almost 13 million. Would that change how you use the platform? Suddenly, from the outside at least, all voices are equal. The game of getting more followers and these other vanity metrics would stop.

Would you treat a DM from somebody with 5 followers the same as somebody with 50k?

While it’s tempting to add numbers and counts to quantify everything in our products, doing so can have adverse and unintended consequences. Instead of allowing for creative freedom, people censor themselves to better play the game.

A single number can change your whole outlook.

So before you add that count to your design, ask yourself: does it provide information which is directly actionable for my users? If the answer yes, add it in, but if not, leave it out and see, maybe people will use your product totally differently.

—jvd ~~~~~~~~~~~~~~~~~~~~

Everyone's on the product team

Many large software organizations split their teams into functional teams: designers doing design, system admins doing operations, developers writing code, and product deciding how the product works.

The idea is simple: let people do what they’re best at and you’ll have an efficient team doing what’s best and in the end you’ll have a coherent product. Product thinks of a new feature, takes it to design to design, who then works with the developers to get it made a part of the product.

While this may result in a product, it also results is a team with large siloed blind spots. Product only sees the tip of the iceberg of that new feature and design makes the feature fit as well as it can, saving it’s energy to fight for another day. After everything’s been decided the work is then passed off the development to make it work.

As a developer it’s easy to acquiesce and just build it thinking, “Hey, I’m doing just what they told me. And besides, it gives me an excuse to try out this new library”. We then try to pass the blame of a poor product off to the product team - afterall, it was their idea.

However managing software is a developer’s job. They’re the only ones with a full sense of the “how” the entire thing works, so it’s up to them to make sure the product doesn’t become compromised. You wouldn’t let a home buyer insist on changes that would compromise integrity of the building and software is no different.

Below are three questions you can ask yourself and your team to help figure out if you should include that new feature in your product.

Is this a core competency?

Are you asking a bear to ride a unicycle? Sure, it may technically be possible for a bear to ride a unicycle, but it doesn’t make sense. Are you building photoshop into your CRM so people can crop their profile photos? If feature play doesn’t play to a core strength of your product, leave it out. The feature will be half-baked at best. If you must include the feature outside your product’s core competency, try offloading the core to a third-party tool whose core competincy is that feature and integrate OR reduce the scope as much as possible.

Where does this feature belong?

Where does this feature belong and how does this fit into the user’s workflow? It’s all too easy to just create a menu for “orphan features”, features that don’t really fit anywhere in the app, but are being shipped anyways.

Ask yourself what users will be doing and what kind of urgency they’ll typically be feeling when using a given feature. If you can’t come up with a better location than the orphan menu, it may be best to leave the feature out until you can.

Who’s going to use the feature and how often will they use it?

Who’s going to use this feature and how often are they going to use it? Is it a report they’re going to run daily? Or is it something they’ll run once when first start using your product and then rarely after that? If it’s something people are going to access often, make it easy to find.

—jvd ~~~~~~~~~~~~~~~~~~~~

Previewing Slack integration

Recently my main task has been creating a subsystem that will allow us to integrate Kwoosh with third party services. We use Slack quite a bit, so it seemed like a good first choice.

The plan is give you the option to enable Slack for your account. Then on each App, you setup where you want the Slack notifications to go. Right now I think Kwoosh will only send them with task related events: new task, completed task, and so forth.

It’s still a work in progress, but I couldn’t wait to share.

As I polish it up I’ll continue to share more videos and screenshots of Slack integration.

—jvd ~~~~~~~~~~~~~~~~~~~~

Don’t over email people

I was recently invited to join a new online forum system by a friend. I clicked the link in an email I was sent and entered a password (they already knew my email address as my friend had given them it).

Once signed up, I clicked around 3-4 pages, joined a few topics of interest and then left. I spent about 60 seconds on the site in total, before seeing it wasn’t really something that I would be interested in.

Four days later and I’ve received 12 emails from them.


4 daily digests for the different topics I had expressed interest in and 8 individual emails for new posts and replies to older posts.

There is no reason to EVER send a new user 12 emails in such a short period of time by default. I ended up unsubscribing from all the emails (they were all different and so required 3-4 different unsubscribe links), and now they will never get the chance to entice me back to their website as they have abused my trust.

What they should have done is start off with a single digest of activity every few days and then as I started to use the site more…ask me if I wanted to get individual emails about every action that occurred on their site.

This way I would have gotten used to seeing them appear in my inbox. Maybe clicked on a few of them over a couple of weeks, and started to build up a routine about visiting them.

It is very rare that a user would ever need to know about EVERY action on their account, and once you overload a user with information they zone it out and you can never get them back. The boy who cried wolf is a good tail to remember…if everything is treated as a “stop in your tracks and read this” event…then users won’t read your really important alerts when they matter.

—jw ~~~~~~~~~~~~~~~~~~~~

Passing parameters to tox through an Ant script

If you are using Ant to process your build and you rely on Tox for testing then you might have had issues trying to pass parameters to tox to use on the environment and not on tox itself.

To solve this issue you need to use a double hypen ‘- -‘ to separate the tox params from those available to ‘{posargs}’.

This then allows you to pass different arguments to the specified environment like so:

—jw ~~~~~~~~~~~~~~~~~~~~

Prevent Jenkins from running all tox environments

If you use Jenkins along with Tox for continous deployment and testing, you may find that you sometimes want to run a different set of environments locally than during deployment.

To do this Tox has a handy built in tox:jenkins option.

This allows you to skip or add extra environments during deployment than locally…maybe so that deployment can fail faster, preventing wasted time waiting for a failed deployment.

—jw ~~~~~~~~~~~~~~~~~~~~

How to split long regex expressions to pass PEP8 line lengths

If you ever find yourself failing a flake8/PEP8 line length check due to a URL regex being over 80 characters, here is your fix.

To this:

—jw ~~~~~~~~~~~~~~~~~~~~

What software can learn from construction

There’s two types on analogies about software: ones that compare it to building a house/bridge/some other physical object and those that don’t.

One camp eople say software can’t be managed like a building because it changes midway through. The argument goes software is different because your 1-story building plan wouldn’t studdenly get requirement to become a skyscraper while and keeping your deadline and budget commitments. The other camp says, well, software is like a building.

No matter the side, there’s a lot we can learn about managing software projects from constructing buildings, specifically with their Building Information Systems (BIM). BIMs give all parties involved in constructing a building a single place to collaborate and share information. The plumber laying pipe can see where electrical is planning to run their wires before they run into conflicts. Information sharing across concerns helps them catch problems before they exist.

After construction is finished, this information can be turned over to the management company, who can then use it for maintenance, planning, and upkeep. The entire history of the building, from plans to the make, model, and specs of lightbulbs in the janitors closest, all in a single location.

In software today we usually manage our projects a lot more haphazardly in 2 week increments. Specs, if they’re written down formally are maybe in a wiki. This in turn which is organized differently for each product, making finding information harder. Finer details are lost in email, tickets, and a bunch of other tools dujour.

An all too common scenerio may be when a designer attach their designs to a ticket to pass it off to development. While implementing the design their’s an bit that too ambitious. The designer and developer work together and find a compromise so they can continue to make progress. Howver, this compromise is agreed upon on Slack and rarely makes it back to be reflected in the designs. Time passes, people move on, and nobody knows why that screen doesn’t match the designs on file.

There must be a better way.

Kwoosh is your software’s fountain of knowledge. A single place to track everything about it in one location.

—jvd ~~~~~~~~~~~~~~~~~~~~

Are your goals really helping you?

At the start of 2008 I made a new years resolution to read more. I set the goal at 36 books a year, with the allowance of being able to miss the 3 books a month target as long as I made up for it in other months.

The first year I managed 33 books. Despite being a few books short I still considered it a big win as I had managed to read a lot more than usual. The following year I read 39. The next 37. Then 37. 36. 41. 46. 42.

Then last year I only read 27.

I had hit the goal consistently for 7 years, but then I started to stop reading. I just wasn’t enjoying it anymore. I had read all the books that I was desperate to read and was then just reading other books for the sake of hitting my target.

I had lost sight of the real reason why I wanted to read more books in the first place, and was now just reading them to hit a meaningless target.

This happens a lot with imposed targets. People will find the easiest path to reaching the goal and this then bypasses the reason why the targets were setup in the first place.

You go from a target of responding to customers within 2 hours to an auto email response. Bringing the response time down to less than a minute, but extending the ticket completion time to days.

From a target of talking to 20 leads, to a bulk spam email of random people you found on twitter. You have the initial aim to reach out strong potential matches and cultivate meaningful contacts. But then you realize this is hard work, you miss a target and get warned by your boss to work harder. You then see that you can play the system by just contacting the first people you find, despite not being a good match. Now you end up hitting your weekly target within half a day, but you get nowhere as the leads are junk.

So next time you set or review a goal, think about what you really want to achieve and make sure the target is taking you in the right direction.

—jw ~~~~~~~~~~~~~~~~~~~~

Small changes unexpected benefits

I’ve been trying to figure out where I’m wasting time during the day so I can spend more time on things that matter to me: time with family, exercise, and working on Kwoosh.

Recently I tallied just how much time I was spending on my phone: 10 minutes because I’m waking up and don’t want to get out of bed, any commercial time if I’m watching tv, commuting time on the train, and 20 minutes to get out raged just before bed on Twitter.

We rearranged our bedroom recently and the power outlet next to my bed no longer being accessible. Which meant I could no longer charge my phone next to my bed.

It’s only been a night thus far but I have three major take aways:

Sometimes there’s unexpected benefits from even the smallest of changes.

—jvd ~~~~~~~~~~~~~~~~~~~~

Don't lie to yourself

Some people start businesses to become rich and famous. Others start businesses because they have no other option. And yet others start them for the craft. To continuously push themselves and their ability.

Each of these businesses have a different trajectory in mind from the founding.

I had a boss that wanted to start a software company with me. We had some ideas for products. His inclination was more the first type. The goal was money, so outsourcing the building of the core product to the cheapest contractor was the logical way forward. The product was just a means to an end. I approached it with the later mindset. Make something great and polish it.

I had thought maybe if I had exposed him to my way of thinking he would see it my way. And he likely thought the same about me.

It didn’t work out.

Two fundamentally different approaches to building a software business. And one one where I could be be comfortable with my choices.

Don’t lie to yourself about what you’re trying to build. Then focus on it with all of your might.

—jvd ~~~~~~~~~~~~~~~~~~~~

Making solid software

With our recent rewrite to Vue and a soft launch of Kwoosh, we’re finally able to use Kwoosh again. With any major rewrite or change you’re going to find bugs or other bits that didn’t quite work as intended. Often these bugs are just oversights in our implementation. We didn’t think about how to handle some detail.

In Kwoosh there are three basic types of users that will use the system: Anonymous Users, Users with a confirmed email address, and Users without a confirmed email address. Some pages in Kwoosh should only be visible to Unconfirmed users, for example the “please confirm your account” page.

To help us quickily and easily allow views to only be visible by unconfirmed users we made a simple view decorator in Python that’s used like below:

Once the code was in production we realzied we overlooked a user-class in our implementation: AnonymousUsers might hit these URLs too and we weren’t handling that case. My initial urge was to fix the bug and move on to more interesting features. Instead I ate my vegtables and decided to use our new testing setup and write some tests for our decorator.

It took me a bit longer to sit figure out how to minimally test our decorators than just fixing the bug itself. By iterating through possible solutions for the test I found some gaps in my initial fix.

The end result is better code, confidence that thie error won’t occur again, which allows me to rest easy knowing that if it crops up again, we’ll catch it before it gets to produdtion.

Getting into the habit of adding tests for every 500 that occurs in prodution is an excellent method to increase the quality and reliability of your software.

—jvd ~~~~~~~~~~~~~~~~~~~~

Artifacts of our work — what makers can learn from Edo-era Japan

During the Edo-era, Japan isolated itself from the rest of the world. All resources were precious. Re-use and recycling were the norm. Not because they loved and cherished nature, though that may have played a role with their Shinto backgrounds, but out of necessity. With limited contact with the outside world, Japan had to be self-sufficient. As a result, communities worked together to make sure that nothing went to waste.

Umbrellas were made of bamboo and paper. Once they started showing wear and tear they were refurbished. The bamboo was repaired and new oil paper was attached. The old paper was sold as packaging material.

Starch extracted from rice was used to repair ceramics. Human waste (night soil) was bought by farmers and used as fertilizer in their fields.

This kind of reuse of by-products was a part of life in the Edo period and the effects still reverberate in modern Japan. Letting excess go to waste even has its own word in Japanese: “mottainai”.

While we aren’t usually concerned about letting excess go to waste, mottainai is uttered on a regular basis in Japan.

I’m helping bootstrapping a product to manage software products called Kwoosh. Kwoosh will make make product management easier and more efficient for small agencies and developers.

Building this product made me realize how much of the work involved isn’t writing code. Phone calls, mock ups, chat history, design: all of this lost in time or hidden in a folder. Valuable artifacts just thrown away.

All of these discarded artifacts of work can be reused and re-purposed, so as to not be so mottainai. What if we tried to save them? Could we make something valuable out of ‘trash’?

Phone calls discussing product design and decisions can be turned into podcasts. Libraries written to help us power Kwoosh can be open sourced. Mock ups shared to illustrate how we do product development. Core ideas and philosophy from all of these artifacts can be broken into articles helping us solidify and codify our values.

What artifacts are you generating from your work and how can you reuse it?

—jvd ~~~~~~~~~~~~~~~~~~~~

Remove as much code as possible

One of the benefits of moving Kwoosh over to Vue and an API backend is that we have managed to remove about 25% of our code base.

Whilst lines of code is not usually a good metric to use for anything. The count shows us that we now have less code to test and maintain…which is a huge win.

Every line of code that you don’t write or can remove is one less line to manage.

Lines of code

—jw ~~~~~~~~~~~~~~~~~~~~

Apps vs projects

The words you use in an interface can dramatically alter your perceptions of it. Words can make it feel cold and stern, or warm and friendly. They can encourage you to write longer responses or none at all.

This is why with Kwoosh we thought long and hard about what we should name our primary object. In most project management software the term “Project” is used. The first thing you do is create a project and then enter data into that project and so on. You then however complete a project.

With software however, things are never really complete. Once software is written it’s usually not finished, instead it moves to the next phase of its lifecycle…maintenance.

Because of this we didn’t like the term “project” as we feel that projects are things that you start and finish. We therefore choose to use the term “App”.

App is short for application…which is what you build with software. They can be desktop apps, mobile apps, web apps, server apps etc.

But more importantly we feel that apps doesn’t imply that it will finish. Once you finish writing your app you have a completed app to release and maintain, as well as the Kwoosh resource of all the info about your app and how to maintain it.

—jw ~~~~~~~~~~~~~~~~~~~~

No feature deploy without writing

In order to keep writing more and talking about Kwoosh. We have decided that we won’t deploy any new feature without first writing about it.

When designing and coding new features we make hundreds of tiny decisions and compromises and we want to write about them more. This workshop is here so that we can shed more light on the design and building aspect of software…so having a mantra to follow should get the ball rolling and have us write more about the small details.

—jw ~~~~~~~~~~~~~~~~~~~~

The fog of building

When you’re working on a project day in and day out, it’s sometimes hard to see the big picture. You get lost in the haze of minor details and the search for perfection. For the past week or so I’ve been lost in the fog.

It started after we managed to soft, soft launch Kwoosh. It had been a hectic week getting everything finished, and then the relief of releasing started to turn into the dread of iterating.

What you had thought was a finished job and good enough to launch, is actually more of an embarrassment, and you see issue after issue and tweak after tweak. This leads you to then continue to slog away on stuff…until you end up lost in the fog.

In the fog you lose your extended vision and so without careful attention you can start to wander off course and get lost. You aimlessly chase after little bugs or sharp edges and before you know it you are going around in circles and not getting any closer to your goal.

The solution is to stick to path you were on. The fog will eventually lift and you will get clarity again. But whilst you are stuck in the fog you have to stick right on the path and have the faith that it will bring you out of the fog to the destination you originally intended.

—jw ~~~~~~~~~~~~~~~~~~~~

Things you need to do to start a project

Things you don’t need

—jw ~~~~~~~~~~~~~~~~~~~~

Things you don’t need to do to start a project

Things you do need

—jw ~~~~~~~~~~~~~~~~~~~~

We soft, soft launched

63 days and 759 commits later and we finally merged our development branch back into master and soft, soft launched.

We will now spend the next week or so just testing things out and checking that everything is running in the way we want it to on the production server before opening things up and allowing people to start using it.

Our development branch before merging

—jw ~~~~~~~~~~~~~~~~~~~~

Scratch your itch

People don’t talk much about building for themselves these days.

Read this article and learn the secrets of writing your own articles to attract people to your website.

You can’t build anything until you’ve setup a landing page, interviewed 100 people, and have 1,000 true fans to send an email to on launch day.

Forget writing software products, take my course to teach you how to build your first product (hint, the product is not software, it’s a course).


When was the last time Apple setup a landing page and decided to scrap an idea because they didn’t get enough signups? Never.

Or Edison? “Didn’t get enough sign ups for the “lightbulb”. On to the next idea.

More people signed up for the faster horse service, guess nobody wants a car.


Build what you need. Scratch your itch. Iterate. Improve. And tell people about it.

—jvd ~~~~~~~~~~~~~~~~~~~~

Technology compromises experiences

When we focus too much on development tools and technology it can cause us to compromise on our user experience.

Rather than using the right tool for the job, we use the tool we’re used to or some the new fancy tool we keep on reading about.

To help combat this I’ve found it best to ask myself for each and every screen the following questions:

The fixes don’t need to be made all at once. It’s often better not to.

We find it better to think of improvements, plan them out a bit and revisit it a week or two later to make sure it all still makes sense.

—jvd ~~~~~~~~~~~~~~~~~~~~

Reworking workflows

Recently I’ve been re-working our Add App flow. This is the first step of any project.

It’s a two step process: enter the app details (name, description, and so forth), and select who should have access to the app.

Users can also have access to multiple accounts, for example a freelancer working on his own projects and also using a customer’s Kwoosh account for their projects together.

If you have access to multiple accounts and you’re adding an app we need to know who it belongs to, so we show a drop down letting you select the proper account.

Setting the account on this first step really serves two purposes:

  1. Tells us who the app belongs to so your team can access it, and
  2. Let us populate the second screen with the users from that account.

Because Kwoosh was rendered on the server and we had minimal front end processing abilities, two steps was mandatory.

We had to send data back to the server in step one so we could display data in step two.

With our rewrite we have a lot more flexibility and we’re able to cut our flow in half, to just a single screen. A huge win.

—jvd ~~~~~~~~~~~~~~~~~~~~

Don't throw it away

When building a product when things don’t quite work as smooth as we want, it’s tempting to throw it all out and start over. Don’t do that.

Starting from scratch lulls us into a false sense of security that we we won’t make the same mistakes that we made last time. While that may be true, we will make different mistakes.

It’s better to refactor. Change one bit of functionality. One screen at a time. This will let you make things right over time and keeps you with a functioning product.

You also don’t have to face an empty project.

This is what we’ve effectively done with our Vue transition in Kwoosh. We’ve rewritten the majority of the code base and things are much cleaner, faster, and maintainable. I don’t know if I could have done it if we had throw it all away.

—jvd ~~~~~~~~~~~~~~~~~~~~