Just in the same way that Google spiders the Internet (automatically crawling through millions of URLs), there are some spiders that have yet to be made that would crawl existing exciting datasets with the hope of producing some useful utility. Here is a list of spider types that I’ve come up, with from purely informational to physical at various scales. I have attempted to put them in order of when they may be achieved. 



Internet spider- Google / Yahoo / Bing etc

Internet vertical spider - there are large range of companies that scrape/spider/record a specific vertical/horizontal dataset


Space spider - We are already collecting tons of data with telescopes from CMB data to, gravity maps and physical star / asteroid positions. Given the resolution required to capture all data in the universe, we still have long, expensive way to go here. 


Geo spiders - we use satellite imagery to collect data about our planet’s surface and now can use drones to get higher resolution/more real time information. We also collect data on the sea floors. Lidar will give us even better laser based data sets of urban / complex areas. Velodyne currently adds individual data sets to an entire cloud map from all incoming sources (e.g. Google self driving cars) to help build more accurate maps.



Product spider - there will be ramp in the 3D data we have on products / objects given the current scanning revolution that is closely tied to the 3D printing revolution


Bio spider / Gene spider - Robust, nuclear battery based soil/species sampler that captures new genetic data by crawling physically around the earth, relaying data back wirelessly. The objective here would be to find new unknown species and genes that may be useful in synthetic biology or medicine. Credit to Sumon Sadhu for coming up with the gene spider. Alternatively, a modified Bdelloidea could “steal” DNA from its targets.


Nanotech spider / materials spider - this spider would essentially be some kind of scanning electron microscope which would look for exotic and interesting surfaces/materials/objects at the nano level. The data would be useful for the nanotech industry, just in the same way that we have scanned gecko feet to inspire new sticky surfaces. 


Brain spider - there is a ton of data that is yet to be collected locked in our brains - thoughts, ideas, emotions, memories. For this we need mobile, high resolution, non invasive techniques. Major privacy issues on this spider. 


Particle spider - this spider would sit listening for particle interactions on a local level and constantly report back. Would need huge amounts of storage and IO bandwidth. 


Abstract dataset spider - this spider would seek to record all informational data sets connected to the Internet. In a sense this is the Internet itself.

Universe spider - this hypothetical spider would be able to collect all data. There are possible limits to how this machine would be able to store all information on the universe inside it and whether it would be even possible to record certain areas of universe and/or types of interactions or data. 

Time spider - this hypothetical spider would be not be limited by recording what is happening/happened already. It would be able to record data in the future and the past. 


Multiverse spider - this hypothetical spider would be able to record data across multiple universes.


Short post here. Just in the same way that you can have a center of mass/gravity of an object, you can apply this analogy to cashflow.

For example, the number of days in your net terms will be be analogistic with the distance that the mass acts and the amount of cash owed would be analogistic with the mass of that object.

For your business you may have some money coming in on net 30 terms, some on net 15, some on receipt of invoice, some in real time (e.g. on credit card) and some being prepaid. This may give rise to your average “cash in” terms to being, for example, net 20 across all the methods. At the same time, your “cash out” of the business will also have its own exit time. E.g. payroll at the end of the month or bimonthly, rent at the start of the month, supplier costs on net 30 terms, tax on net yearly terms.

When you work out your center of cash in and your center of cash out, you can them compare them to work out the “center of cashflow”. I find this useful for predicting Heyzap’s cashflow or credit turnover period without using excel models.

By mechanical/vector analogy, if you have positive cash turnover period, your business will start to spin in the right way, just in the same way that if your “center of cash out” or “burn force” (representative of your “mass”) is a smaller vector than the “cash in”. However, if you have it the wrong way round, the business will start to spin out of control. 

One of the more practical things you can do to improve your credit term over period is to get payments occurring prepaid or in realtime with tools like Stripe Connect, negotiate contracts to short net terms and to delay spending. 

It amuses me that there was a coincidental mechanical analogy behind “credit turnover period”.

P.s. sorry for not fully explaining the analogy for non mechanics people and not making a diagram.

Aerographite, is lighter than air. Yes, lighter than air. Recently discovered by German scientists in 2012, aerographite is 75x lighter than Styrofoam but the same strength. It is made up of a mesh of interwoven, linked chain of carbon tubes which are 15nm in diameter. 1kg of the material takes up around five cubic meters of space. Think about this, it is insane. I can envisage airships that don’t use hydrogen or helium but use a “solid” tank of aerographite, meaning there would be no risk of explosions from the flammable hydrogen and lower risk of bursting the blimp. Also, you would not need to refill the blimp with hydrogen/helium leading to greater long term efficiency and potential applications that don’t require landing (e.g. surface imaging).


You might ask yourself, how are you going to come back down to earth if you cannot release some of the hydrogen/helium? One could use a high capacity water condenser to condense water vapour into tanks to use as a ballast and/or use engines to guide the airship down.

Typically, a standard Goodyear blimp will has around 200,000 cubic feet of helium creating around 12,500 pounds of lift. Helium is around 7x lighter than air. Aerographite is also around 6x lighter than air. So we can say that the size of this aerographiteship would be slightly bigger than a normal airship.

The material also has an interesting property: after 95% compression of the material, it is possible for the material to return back to its original shape. This means the blimps could be packed into a deployable unit 20x times smaller for later expansion.

Another application could be high altitude wind turbines that hold their position high up without having to refill expensive helium tanks. An advantage of being high altitude would be the wind speed is fast and constant. Altaeros energies Inc should also think about this material for future builds.

Normally it takes around 20 years to get materials into mass production (see history of carbon fibre). The main question remains, when will we have aerographite in mass production?

One other limitation will be creating aerographites that can support themselves with the air inside the material “pumped” out of it (to truly achieve being lighter than air). In practice, getting a real blimp to work will probably be made out of a future version of aerographite or another aerogel that is super strong and light, one that could self support itself without collapsing in on itself if the air between the meshes of nanotubes is pumped out. A partial vacuum will have to be created inside the aerographite structure without crushing the aerogel. This may be the fatal flaw to the idea or at least the next problem to solve (i.e. given that the material is superhydrophobic, maybe a thin shell of water could be put around the aerogel or some similar exotic solution). 

Credit to Millennium Airship Inc for the image.


Just in the same way that “work in progress” aka “WIP” can put an additional burden on a manufacturing assembly line, reducing production efficiency and quality, so too can it place a major burden on software development. “Code in progress” is something that all people involved in making software should be aware of and know how to deal with.

How does it arise?

Business and product priorities are constantly changing in a startup, especially startups that are iterating quickly and adapting their products to new data or client feedback. This means roadmap priorities for small-to-large projects and tickets are also changing. (A ticket is defined as a task or element in a bug/task management CRM).  A project that was important last week can fall by the wayside because of new priorities or suddenly urgent matters. This can lead to engineers jumping to new projects before they have finished other tickets or projects.  As time moves forward, if the team doesn’t return to that project, the “work in progress”, “code in progress” or “CIP” starts to compound and significant projects/tickets can sit around uncompleted for too long.

Engineering problems

CIP is going to create issues for your engineers and engineering team at large:

  • Satisfaction: An engineer will have put hard work into the project/ticket without the satisfaction of releasing it.

  • Quality: Original specifications or communications might start to become fuzzy over time.

  • Block releases: The tickets/projects can also technically block the release of other dependent tickets and block other pull requests.

Managerial complexity

Having multiple unfinished projects/tickets when developing software can sit in the back of a product manager’s mind, clouding their judgement of what needs to be done next and increasing the complexity of load-balancing a roadmap.

Communication noise

Having CIP also increases the noise in communication:

  • Assumption of completion: people start assuming something has been completed if it was started weeks before.

  • Variability: Because of the added complexity in roadmapping, there will be a variability in expected completion date of the project, making it harder to plan QA, launching product, marketing and operational use of the project/ticket.

Production burden

Ultimately too much CIP will lead to reduced team productivity:

  • Focus: communication issues and increased complexity combine  to reduce the focus of individuals and of the team.
  • Quality/speed: Having too much CIP means a frequent reduction to the quality and speed at which you will complete tickets.
  • Impact on creativity: Having too much CIP all the time, means reduced time for alternative unplanned projects. If you always have a project to fall back into, the natural breaks in work that allow for creative time may be impacted.

Wasted Mindshare

Projects that are in progress or almost finished will constantly be on the mind of the everyone until they are released. Not only will the engineers waste mindshare but so will the product managers, management and rest of the team

Solutions to getting the optimal CIP

There are ways to get down to reasonable and optimal levels of CIP:

  • Tag out your CIP: Here at Heyzap, we tag out all the work in progress in asana.
  • Kill the ticket: If the project has been sitting around “in progress” for a very long time, you have to ask yourself - is it really that important that it keeps getting bumped back? In this particular case, you may want to kill that ticket/project.
  • Pass the ticket over to someone else: Yes, passing it off to someone else can be the best way to solve it if they are more specialised or wrote the original area of that code base and have come back from holiday.
  • Modularize projects as much as possible: Breaking down tickets and projects can allow for more frequent releases and prevent CIP.
  • Constant iteration: The length of time something will remain a work in progress is going to be proportional to the project size. 

But! A certain amount of CIP is a good thing

There are various situations where some CIP will naturally be good to have and there are no hard and fast rules as to a safe numerical threshold for the percentage of projects in CIP mode - you have to go with your gut.

  • Change in priorities: Sometimes it is essential to pause a project and work on something else due to priorities. Having a hard rule of zero CIP would be counter-productive in this case.

  • Rotation: Sometimes working between 2-3 projects/tickets can give you time to solve a technical/intellectual or people-based blocker, that is preventing the ticket going out. You might naturally solve the ticket by sleeping on it for example.

  • Waiting: Sometimes waiting can solve the project/ticket e.g. a alternative solution pops up that was a much simpler way to solve the ticket.

  • Inevitability: Some tickets being CIP are unavoidable - e.g. a script running over a few days; there is no way to prevent this from being CIP.


CIP differs from the classic work in progress that is seen in a manufacturing context. Just in the same way that the physical industries deal with WIP, it is worth giving some thought into how we can make better products by being aware of CIP. As software development moves from an art to a science, just as manufacturing moved from an artisan skill to mass industrialisation, we must learn to leverage the subtle effects that govern its mechanics.

blog comments powered by Disqus