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.
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.
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:
I felt super rested when I woke up, no “going to bed” and then spending 30 minutes on YouTube.
No mid-night out-rage cussed by checking the time on my phone and seeing a notification from the New York Times.
I didn’t lay about as long when I woke up so I had an extra 10 minutes in the morning to take the dog out.
Sometimes there’s unexpected benefits from even the smallest of changes.
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.
With our recent rewrite toVueand a soft launch ofKwoosh, 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.
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,mottainaiis uttered on a regular basis in Japan.
I’m helping bootstrapping a product to manage software products calledKwoosh. 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 somottainai. 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 beopen 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?
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 withKwooshwe 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.
In order to keep writing more and talking aboutKwoosh. 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.
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 tosoft, 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.
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.
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 ourVuetransition inKwoosh. 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.
As with all things in software design, it’s always a good idea to sit down every so often and think about the purpose of that one thing. Let’s have a think about navigation.
A lot of the UI ofKwooshis navigation. We have a masthead with notification and user data. A sidebar with apps and more popover navigation. Breadcrumbs. On-screen links. Page navigation. Etc.
Navigation should be like oxygen, you don’t notice it until its not there.
Recently I’ve visited a few major sites and have been struck at the lack of navigation and found myself having to use the back button to get around. If users are having to use the back button as a primary method of getting around your site you have seriously messed up.
So what we have tried with Kwoosh is to add in a lot of redundant navigation. Everybody uses software differently and so providing different ways to get around allows everybody to find their feet and navigate in a way they feel comfortable.
One of the first things we did withKwooshwas to build a pretty robust deployment process. It was probably a bit of an overkill at the time, but it was a fun project and a new challenge to throw ourselves into.
When starting the Workshop I copied a lot of the deployment process over, so lets take a look at how this site works.
The Workshop is a statically generated site usingJekyll. This means that its just a bunch of simple HTML files and a few images. There are no complicated databases, frameworks or scripts…at all.
We begin the process of writing a new post in a text editor andMarkdown. We write simple posts that reflex our design and ethos and then commit them to a git repo. This is then where the magic happens.
Whenever we push commits to our master branch a web hook pings our deployment server to let it know there is something to do. Our development server runsJenkinsand this receives the ping and gets to work.
For all our deployment processes we have three stages. Build, test and deploy. We therefor have three jobs with these names within Jenkins that are run in that order.
For this site we only use Jenkins to call anAntscript where most of the work is done, and this also follows the three stages of deployment.
In the build stage we build all the resources we need for the website.
Primarily this means that we call Jekyll and that spits out all the HTML files for the website. We then run our CSS through a linting process to check for errors and then minify it. If we had any JS we would also do the same at this point.
Finally we run all the image assets through a minification process using a series of different command line tools for each image type. This removes any un-needed data from the image files and reduces their file sizes…by up to 40-50% in some cases.
We then move all these files into a build directory so that everything is nicely organised.
Normally we would then run a series of tests against the content in the build folder. We don’t yet have any for the Workshop, so this step is just skipped.
If the tests all pass (which they do) we then begin the deploy process.
For this website that means uploading toAmazon S3. We uses3cmdto sync the HTML files to one bucket and the assets to another. It then invalidates theCloudFrontcache, and after about 30 seconds and a refresh the new content appears on the site.
The whole deploy process takes about 15 seconds to process and then another 30 or so for CloudFront to start serving the new content.
And that’s it. All we have to do is write and commit. No messing around with FTP or updating Wordpress. We commit and go.
Over the past few days I accidentally created an API for Kwoosh.
It started out by thinking about how a delete link should work, and ended up by cleaning up a lot of code and making things both simpler and more useful.
We probably won’t tout the API itself, but we will use it for the front end of Kwoosh and in theory a user could use it to create their own apps.
Once we decided to do a RESTFUL delete request, the easiest way to handle it was to create a method for each allowed HTTP method per view. This then soon grew to remove the non-RESTFUL endpoints we had and merge them into a REST friendly environment.
It then turns out that the rest of the work we have been doing to move to Vue.js, allows us to easily select just the response data to return. And with that we have an accidental JSON API.
Changing lots of stuff and making it simpler and easier to manage from both a user and developers point of view.
This week everything has just started to click together. All the generic views and classes have been completed and implementation has been a breeze. We have gone from having to think about what we are coding, to copy and pasting code into the views we want.
All of a sudden the mentally hard work has finished and we are completing ten plus pages at a time and everything is clicking into place.
I’ve had a post written for the workshop for about two weeks now. I haven’t posted it yet as I wanted to add images. It would take me 10 minutes to take and upload the images, but I’ve been putting it off.
This one little thing of adding a few images has added enough friction to publishing the post that I’ve put it off for weeks. I could (and probably will) just post it without images, as done is better than perfect and not done. But that tiny bit of extra friction has stopped me in my tracks.
Next time you find yourself stuck, try and see what is creating the friction and if its not critical just remove it. Remove all the friction and see how fast you can get things done.