When to Delete Everything

Did you notice how we create complexity to solve complexity? I did, and then I wanted to delete everything.

Tabula rasa means blank slate. It is coming from the requirement of erasing by melting the layer of wax used to write things on back in the Roman days. In time it has transcended this mundane meaning into a full fledged philosophical concept. I am asking when to dive in it.

All systems decay because of increasing complexity.

Look at the world. Most of the problems we’re experiencing are because we kept adding layers or abstraction, special cases, dependencies, external assets and most likely other forms of complexity.

Complexity tends to increase because of constraint. Constraint acts as a factor of progress in the blank slate phase, or initial state. In the beginning, constraint harbors complexity-decreasing innovation. However, in later stages constraint creates exclusively complexity-increasing innovation: time constraints bring dependencies, resource constraints bring external assets, architectural constraints bring special cases and finally, the biggest barrier, human capacity of managing detail brings layers of abstraction.

All complex systems have a decay level inversely proportional to decoupling. That means we have fake complexity, a complexity which only appears to us because we don’t see the parts of the system, either because we don’t filter out information correctly or because our information is incomplete.

little known fact of life, pictured above

The opposite of complexity is not simplicity

A simple system solves a small problem. That is the biggest mistake we make in reducing complexity: simplifying systems. By introducing actions that increase simplicity, the system will by default not be able to solve the same problems. We’re tricked by ourselves because the system will be able to solve the same kind of problems, just not the same problems.

The generator of complexity is evolution. We’re constantly pushing systems to do more and we try to reuse as much as possible, because of constraints. So the system evolves. It appears as if it is getting better, flabbergasting us with the decline in effectiveness.

It is the same principle found in biology, and probably the main argument of evolution based atheism: if we were made from a blank slate there would have been better decisions in place. But we were not, we are features stacked on top of an ancient chassis.

Evolution granted us access to capacities far beyond the original design intended, but by doing that, the overall system decayed in a state of immense complexity: a psychological level of abstraction that is almost disconnected from the basic needs of survival (suicide), brain development added the huge dependency on others (immense social needs), our capacity of making tools brought in huge amounts of external assets in one’s life (extraction of resources from environment) and finally our self reflective natures that make our inner selves look like an endless spiral of nested special cases, a kind of expert system that is good at running only one single precise life, yours, not any other.

Use clarity

So what is the opposite of complexity then? Clarity. Clarity is the product of adaptation.

We are too afraid to start over. We repeat the “rewrite” mistake whenever we start over.The rewrite mistake is the bad assumption that a start over includes rebuilding what is already built. That’s why revolutions suck at solving social problems. When we rewrite the basic things we start by being the same flawed agents so we incorporate the same mistakes all over again in the new design. Plus, we loose all the countless iterations of progress and advancement which perfected regions of the system to crystal clarity.

Starting over implies a few steps:

  1. identify if the problem is that big in the first place so that it requires a system
  2. export processed and formatted data from the current system in all aspects defined in the problem
  3. open the current system in all places that affect the data it exports
  4. build the new system using data storage and processing from the old system

Old systems can be adapted almost endlessly and there is only one kind of event that makes adaptation impossible: cataclysmic events. There are two kinds of cataclysms: acute and chronic. Acute ones disrupt the world of the system so deep and hard that the problems it solved are no longer available. Chronic ones are pervasive and subversive, they steadily but relentlessly alter the nature of problems, so much that at some point the system solves irrelevant problems. The meteor that changed the climate which led to the dinosaurs going extinct is an acute cataclysmic event. Humans are a chronic cataclysm for ecosystems. New types of exclusively digital money is a chronic cataclysm for the banking industry. And so on. Only evolution solves cataclysmic events.

So, in short, tabula rasa should always mean, bring another tabula and leave the curent one as legible as possible.

small update

How to build software in 3 steps

1) First create an UX (user experience)

a) What is the experience?

b) Who are your users?

  • personas
  • market research

c) What do your users want?

  • user stories
  • customer journey

d) How are you going to give them what they want?

  • communication design
  • information design
  • funnels design
  • UI design

2) Second engineer the IA (information architecture)

What will you build?

  • core product functionality (aka MVP)
  • product features
  • support features
  • tooling

How does it work?

  • software entities
  • information flow
  • database design
  • application design

How will you build it?

  • technology stack
  • conventions

3) Third handle the PM (project management)

Who will do this?

  • team assembly
  • team management

What do we need?

  • critical path
  • resources
  • budgeting
  • effort allocation
  • vendors

When will it be done?

  • product roadmap
  • product and work breakdown structure and/or backlog
  • agile and/or waterfall procedures
  • velocity and/or man-hours estimates

An ode to JavaScript

{ } in you is the beauty of endless opportunity,
And in [ ] the confidence that I surrender to.

For this. I feel the enthusiasm of knowing where I am,
With $ silently watching over my step.

( ) gives me the keys to the kingdom,
But new reminds me that the world is a hard place to change,

But i still try to,
Because prototype has a godly lure.

Maybe broccoli loves you

The story of launching our mobile site

Greetings from Romania.

Running a start up, while fending off vampires, can be a tough business. Being so busy with these blood suckers, we postponed our mobile website just until Father Google woke up one day and said:

“that information which is not mobile friendly, shall be cast into oblivion”

You know how sometimes grown ups seem to just make up all these crazy rules? Like:

“no ice cream if you don’t eat your broccoli”

“Mobile website, or no first page for you!” Google, 2015

Aww, the horror! Just thinking about the delicious bio and organic traffic we’d loose for desert, killed us a bit on the inside. Well that, not vampires, was too much of a scare to fend off; something had to happen.

First we called Transylvania and had some werewolves guard our door from vampires. You know, so we can concentrate. Then, immediately, we started to implement our small-device-mobile-enabled-touch-friendly version of the website.

It was not an easy task, after all we make the best flash sales online store in CEE — vivre.ro — that’s our thing. Yes we rule our hood, but we’ve got vampires what else did you expect.

Truth being told, our favorite aunt, Miss Data, told us once that we already had broccoli lurking at the bottom of our plates when we weren’t paying attention. They were disguised as an ever increasing mobile traffic in our analytics. She even gave us a nice picture:

broccoli invading our plates, aka mobile users and their love for their phones and selfies

At first we tried to tackle this with a mighty app. So far it’s been more app than mighty, you know like when you were trying to feed those broccoli to the dog. The dog ate them only if you also put a juicy stake on top. Here is a chart:

Yes, the app was not nearly as fast growing as our mobile enabled traffic. We were cornered and had no other option than suck it up and start digging the greens.

Us analyzing if we should do a responsive website or a specific mobile only experience

After much thought we decided that creating a mobile first, responsive experience would push the project way too much into the future. In Romania the future is always uncertain. We learned that what you can have today, might be gone by Sunday — so we decided to implement a separate mobile specific experience.

We used a feature of Yii, our framework of choice, named themes. This way, every view (page) from our desktop version could be overridden by simply making another file with the same name in the new theme. We employed twitter bootstrap for all the annoying grid/viewport management so we could concentrate on the fun parts, like rendering handlebars templates from our API. We had an API but no mobile site. It hurts me to even write this.

Like respectable vampire fending, werewolf guarded, young rebels we were opinionated and so we set to find if this whole mobile fuss was up to any good. Our big brother from his marketing tree house, lifting custom audiences with one hand while reading Ad Age, his odd passion, told us that when he was young like us, he also had to eat his broccoli or else, and now look how strong he got. He said it was obvious broccoli is good and laughed at our experiment.

That, puhlease, did not stop us. We started this experiment to see if conversion rates were still the same or better, considering our enhanced touch screen usability, retina ready assets and all. We went to papa Google and asked him to be the judge of this experiment, hoping in our young hearts to maybe, miraculously prove him wrong. In three days the results showed a 100% increase in conversion rates and, as it settled to more human-graspable percentages in the following days, the experiment gave the mobile/broccoli/grown-up-rule-thing 99% chances to win.

Reluctantly we started the vegetable, err mobile, feast with our favorite sporks. We had to solve really important problems too, like if should we use a hamburger, döner or a kebab menu, and the other things such as: one column or two column layout: which one provides a better experience, minimum tap zones for our controls and navigation, should users be able to log out on mobile? You know, the usual suspects.

Then the Q&A sessions flowed right in. We even tested on an Windows Phone, we’re that thorough. Yet we kept this to a minimum because as trained agile ninjas we carved out an MVP version of the new feature and spot on the day the new google algorithm started to take effect, our mobile optimized experience was up and kicking.

Some time passed.

Then behold:

All Green, Grown and Healthy!

Week over week we felt like Popeye when that spinach turned him into an instant body builder. Growth all over!

Scientific quantification of the overwhelming results revealed that:

  • The increased conversions must have come from the fact that users could actually tap that buy button
  • The higher number of transactions and unique purchases are owed to the UX being streamlined for the task at hand. On mobile devices users are even more task focused than on desktops since apparently tapping implies a lot more muscle groups than mousing around.
  • The bigger quantity of purchases was because the time on site increased a lot and aunt Data explained this correlation to us a while ago: it seems like users buy more when they spend more time browsing your site, imagine that!

Currently we are iterating over our mobile site with joy and hyper high expectations. As this mobile and devices trend is one way and the app ecosystems seem to flat line really fast, with enormous cost for growth, the mobile web looks like the avenue to walk on with full confidence.

Jokes and funnies aside, if you’re still not device friendly and you run a web business, you are definitely missing out on the best opportunity available for development right now. With very little technical effort we offered our users an optimized experience and they rewarded us in return with booming metrics all over the board.

Oh, and apparently broccoli is awesome:

We love our mobile users so much now! Just look at that wide smile ☺

Go mobile!

Introducing Raster PHP

a framework even designers can understand ^-^

Ok, this has to be appreciated at least for the nerve — making a PHP framework in 2014, the year of the node, is both uncool and hard to promote. But you’re here, and so please carry on, you might be impressed.

Raster PHP is a super small footprint collection of ideas — that are weaved up together in a cloth of magic coding happiness.

This is a framework for web sites, not for web apps. For web apps you probably don’t even need a PHP framework anyway — because if you make it in PHP you’re gonna be the laughing stock of all your nerdy friends …., just think about it — the horror! O_O

However what makes Raster PHP stand apart is the awesome comments based templating engine that does not break the layout, nor does it kill the dummy content. This is made possible via magic and some little used model view controller variant named MVC-pull.

A standard view in Raster PHP is along the lines of the below example:

<!-- res.head_part -->
<!-- /res.head_part -->
<h1>A list of things</h1>
<!-- render.tasks.list -->
<!-- print.task_name -->
Lorem ipsum
<!-- /print.task_name -->
<!-- /render.tasks.list -->

What this simple view does is the following two things:

  1. Creates a reusable part named head_part which can be called in other views
  2. Loads a plain php class named tasks and calls its list method

Raster PHP, like any modern framework, is based on a set of conventions but, unlike some modern frameworks, makes those conventions configurable. In our example above tasks is a plain straightforward PHP class:

class tasks

function list()
    return array(
“task_name” => “Walk the dog”
“task_name” => “Fill in groceries list”
“task_name” => “Convince people to use Raster”


This simple example will output the list of tasks as the model offers them. In Raster PHP the model always returns only data which the view uses to update itself. In this case the array will produce this result:

<h1>A list of things</h1>
Walk the dog
Fill in groceries list
Convince people to use Raster

Yes, its that simple. The models can do anything that can be done with PHP, connect to databases, load files, calculate the EBITDA of your next venture — the works. The views are plain HTML with some comments that execute the models you tell them to and show the data nicely formatted.

With Raster PHP you can do many other things, but they are all completely optional:

  • use plain SQL as a form of pseudo-ORM
  • manage forms in all their glory, with auto field value completion
  • have an API that others can use
  • make a full blown CMS

All of the features are documented (mostly) with annotated source code that walks you step by step trough the logic of how a Raster app works. But you needn’t know that necessarily.

You could have your PSD2HTML and comment your way in them based on the logic above, then have some dev implement the PHP side.

Wait, there’s more good stuff

Does it work?

I have used it in personal projects but also production quality websites and so far it behaved very well showing no drawbacks. Since its all about fast string operations and a few loaded files the performance of Raster PHP turbo style ☺

Raster PHP is portable

The first version of Raster PHP, named Spartan PHP because, well, it was so spartan, is ported to both Code Igniter and WordPress. I am mentioning these, which are old unmaintained projects, just to note the flexibility of Raster PHP — one can easily encapsulate all the nice in it and also use the heavy power of big frameworks or apps but, at the same time, achieve the beauty of html comments templates.

Raster PHP is fully event based

Everything the framework does from detecting what view to load for some URL (routing) to executing template parsing and models fires events. You can easily hook to these events and change the way everything works in one line of code:


Raster PHP has powerful templating

In the example above only render was shown but raster has a wide selection of ways to output data in views such as:

<!-- print.model.method -->
<!-- print.if.variable -->
<!-- print.@attribute.variable -->
<!-- print.+attribute.variable -->
<!-- dry.view.res_name -->

These other template tags offer a completely flexible way to think about your website using MVC-pull:

  • print will output data as a string wherever you place it
  • print.@ and print.+ will output data inside HTML attributes
  • print.if will now show if the variable you specify is false
  • dry will bring parsed resources from other views
  • etcetera means there is a lot more ☺

Raster PHP uses RedBean and SQL

RedBean is a one of a kind ORM that allows you do connect and operate any kind of database without any kind of advanced functionality. But a model in Raster PHP will allow you to call simple SQL as overloaded methods of the database class with arguments.

Raster PHP comes with various ready made models

Although a work in progress, porting them from an older version, Raster includes a basic CMS model that works on any content, a pagination class, auto API, i18n, validation and so on.

Raster PHP is a framework that adheres to the microPHP manifesto and because of that your projects will be more fun and less spaghetti!

What’s next

With this article i am opening a series on Raster with the hope of spreading the word about a clear and definitely useful way of building dynamic websites: using Raster PHP.

If you want to know more don’t hesitate to contact me @andraganescu.

If you want to use the power of the fork … even better, contributors are welcome with open arms contact me @andraganescu or visit this Github user.

Hopefully this will not make you leave Laravel in the gutter, because that will cost you your artisan status, but it will open up another nice choice for use when the project you are working on might be crushed under the grangantuan weight of a fully fledged, IoC and Eloquent enabled framework.

If you wouldn’t do your job for free, its ok to carry on doing it.

And have a peaceful mind and a happy life too

A while ago LifeHacker articulated this title for some article:

If You Wouldn’t Do Your Job For Free, Then Quit

Sure, it sounds good for a headline, but in reality this is a really bad advice.

Why? Well, consider the average person. Not only do they not allow themselves to be so independent because of family and other life-collected restraints but, even if they did allow it, i highly doubt you’ll get so many people who would:

  • take coal out of a mine for free,
  • be a cashier at the super market for free,
  • be a cleaning professional and wipe dirt all day long for free
  • or sew together 100 shoes per day for free.

This advice fits for probably less than a fifth of people, and this privileged group does creative, adrenaline rushed, high potential activities. But for the rest 80% or so who are stuck in a rut or have careers that involve very high responsibility or bad working conditions or very many years of study, and so on, there is no such concept of doing it for free.

Actually this kind of advice stems the “crap” that every freelancer of the world who “likes” their job has to put up with:

Q: Your work is so much fun why do you charge so much money?
A: Well, because money is so much fun too!

Its fun to program for example. But in this example a programming job not a hobby is not about the fun of spending 15 minutes hacking a neat program that beeps the speaker — it is about crawling endless files or spending 15 hours a day debugging your own stupidity. You must be out of your mind to do that for free, and yet i wouldn’t wouldn’t quit — the money is really nice and its a well balanced investment of my effort.

Takeaway for skimmers 😛

Along similar lines I liked a similar advice much, much better (cant find the source but it was a speech somewhere in Japan):

Find something that you like doing and keep doing it over and over. Eventually you will get so good at it that people will start paying you to do it.

This is a very good advice at any phase of life because it describes how the entrepreneurial spirit gets nurtured and how it can spawn life changing events no mater what your age or what your current social position currently is. And even more this advice doesn’t invite you to quit your job and give your spouse, your land lord and yourself many extra gray hairs.

Nevertheless just note that advices like these are all about this type of connecting your happiness with the world: happiness with work, happiness with love, happiness with the weather, happiness with the quality of your clothing or with the brand sewed on the inside. But happiness is only connected with you. Stop each day and consider what did you do which made you feel happy? … found nothing? Well definitely it is not because of your job, nor your significant other, nor the size of the TV or the rain outside.

Deadline Dread

There are three types of deadlines: rational deadlines, abstract deadlines and real deadlines.

Too often lately “agile” has become either an excuse or a “solution” for deadline phobia. Because things cannot be endlessly fiddled with, generally any stakeholder involved in the development process will, at some point, require something done in a certain timeframe.

One of the problems of deadlines is that they are wrongfully understood as the end. Here comes Iterative Development to the rescue: deadlines are just different stages that the product goes trough.

Another problem with deadlines is that they tend to be perceived erroneously as huge walls that are approached at full speed — and just because of that they cause stress and poor execution.

When a deadline is regarded as a roadblock that you’ll smash into, unless you can somehow do a stunt on it, the solutions to come up with are poor: bloated teams, cut features, sliced specs, dirty hacks, bug ridden results.

A deadline is just this: the end of the timeframe that starts now.

When you look at it this way it no longer frightens you. Its just a constraint imposed on time for some reason from which it results an interval, a timeframe, made of a given number of days. Your problem is what you can do best with this amount of time that you have, a problem well put by Gandalf about life in general “all we have to decide is what to do with the time that is given us”.

To escape deadlines we have a quick and elegant solution that is called MVP — minimum viable product. The idea is that you don’t care about the date of the deadline, but only about what can you currently can deliver in that amount of days. MVP teaches that you should only strive to implement the core features that allow deployment, and no more.

The art here is to be able to self asses honestly and clearly. There are situations in which self assessment is hard such as when the team is just assembled and you really have no idea how fast you can do anything. There are situations in which clarity is hard such as when there is no study on the market or customer and you’re working on assumptions. Assumptions are usually false unless they’re scientific theories which are usually false too.

MVP however works very well, even in bad situations, because the theory is sound. As Jon Radoff put it, an MVP is not a minimal product, its a product that is small enough to be affordable and viable enough to be deployed. Affordable can mean a lot of things and it includes: cost effective, timeframe realistic, know how realistic and so on. Deployable can mean many things from saleable to functioning, it depends on what you set sail for.

MVP is not dirty coding hacks to quickly deploy crappy products that nobody will use. MVP is not cutting out features to create undifferentiated offers that nobody will notice. Lets look at the acronym again: MVP — minimum viable product. Minimum means the least required padding that is absolutely necessary around the core of the product. Viable means it has to work for the customer, to solve a problem, to be a scratch for some market’s itch (markets include segments of customers you already have). Product means it has to be self contained, explainable on, the eternal cliche, “back of a business card” space.

The key to implement MVP successfully is to start backwards with it. First of all think about the Product. First of all is it a product? If its not a product you have a major problem because you will not be able to make a project out of it. This tends to be the case with ideas, inventions, generic solutions, avant-garde creativity and weekend projects. Also if the business is up and running consider whether the problem at hand is not customer support, a marketing and communication issue, a bug, a nice to have and so forth. Then do the famous Feynman exercise and try to explain what you’re trying to accomplish to a total noob and see if they get it. As the master of this practice put it, if you cannot explain something to the layman you have not understood it yourself.

So the Product part in MVP means clarity, firm affirmations about what you want to accomplish, why and how is it adding any good to the world (and thereby producing some profit of course, yes even charity or NGO projects produce the so called social profit).

Then continue on this backwards path to the Viable part. Viable means identifying the core of your Product. It is not to be confused with the description of the product! The core is the definition of what is essential to make the Product work. For example, the core of a consumer search engine is result relevance. Its not indexing of data as you’d expect, that is a function that supports the core. The core of a search engine is to help the user find. If it were an exhausting database then, and only then, indexing would be the core.

This then brings us to Minimum. After you have clearly defined what you want to accomplish and found the core of it, its time to identify what is the least necessary support for the core to exist and function. In the not Google example above, a large chunk of web indexed is necessary so that you have something to search into, but minimum means you don’t need the entire Internet, even that not evil company merely searched trough Stanford’s web in the beginning. So one website was the Minimum required to make the core — the relevance algorithm — work.

But having the MVP method in mind and explained lets get back to deadlines. As i said above, a deadline is merely the other end of a timeframe which starts now. There are three types of deadlines: rational deadlines, abstract deadlines and real deadlines.

Rational deadlines are the best kind.

They usually are a conclusion to some sort of plan. Because of that, a long list of assumptions has been made before the rational conclusion has been reached that some deadline is set. Most of these however tend to be too optimistic because people have the bad habit of planning for way too large spans of time. However if the time span is reasonable and the planner capable, its the best type of deadline you can get. Its also the most flexible type because you can adapt constantly to change.

Abstract deadlines come from a need.

Cash flow is most often the need to be solved (there are numerous companies effectively ran by the sales plan), but other types exist as well such as personal reasons of the people doing the planning (fame, promotions, bonuses, bragging rights), dependencies inside programs or large projects (i can’t do this if i don’t finish that — which by the way is an architecture problem not a project management one) and other similar things. These are the deadlines which are probably the most missed in the world and they are the main cause of bad project management. I don’t have a statistics for that but its not hard to imagine the pressure and stress coming from a vague restriction that cannot be properly understood by everyone involved and then the poor results and low productivity rising like a malevolent Saturn in an astrogram.

Real deadlines come from the real world

… and 99% of the time they exist because we use a calendar: events, celebrations, ending cycles (financial, executive terms etc.) and so forth. These are the deadlines that caused most failed products in history (e.g. Windows Vista). Why? Because you cannot fiddle with the placement of Christmas in the calendar or the quarter reporting of a public company. You absolutely have to deploy by that date, and because of that crappy products spawn endlessly.

In managing software production projects you will have a mix of these types of deadlines and this is the exact reason why you should keep the tabs on wether or not you are following best practices or if you have strayed.

Rational deadlines are solved by Agile Development Methodologies because they will reveal your speed and they shorten planning spans resulting in the magical ability to foresee the future (because it gets to be a week away) and take far more rational decisions.

Abstract deadlines are solved by doing Iterative Deployment because they are like a medicine for a health problem, gradually solving it by small amounts of substance. If you’d take the whole amount of antibiotics to solve a bad bacterial flu in one day, you’d have a bigger problem than the flu in the next ten minutes.

Real deadlines are solved by the MVP you put in place. If your MVP is correct, its not a watered down version, a dumbed down deployment, a trick to fool customers in and so on, then chances are you will have it when the event happens. In the case of this type of deadline its important to realize that you actually have a great advantage in that you identified something real to tie your product to as its a lot better to sell or launch when everybody is waiting eagerly than in the enormous noise of a random day. So treat it like an opportunity constraint and mind your MVP.

So, with all that being said, no more deadline dread!