Here’s my take on it.

WARNING: The views expressed here are solely my opinion, based on personal experience and observations.

Software as Civil Engineering

I have heard software developers describing a feature to higher-ups by comparing it with building a house. That type of comparison for me is totally bogus. Here’s why:

Software developers never built a house. Ever.

I mean themselves, by hand. Ok, maybe some of us have, or finished a basement. But even when drawing that comparison they’ll have the mental schema of bricklaying. If you have ever seen a house being built, it takes hundreds of different trades, and skills, all at different times in the house-building process.

A civil construction (a building for the uninformed) is a tangible thing (you can touch it).

Building some concrete takes time to put it together, takes time to replicate it, takes time to clean it, and takes time to tear it down. Building software is merely giving instructions to a machine on how to do things. By how to do things, I mean telling a computer how to transform a file (or a set of them) into another file. If you want to be specific, how to transform a long sequence of 0s (zeroes) and 1s (ones) into another sequence.

A consequence is that to “build” software it becomes as simple as pressing a button and watching the computer do its job. And if you’re curious, to replicate, to clean or to tear it down, it’s also a matter of pressing another button. Ok, maybe calling “make clean” if you wanna geek-it-out.

If you still don’t follow or agree with me, here’s an example:

Imagine you’re building a software “house”. You don’t create each window by hand (technically you can, but it defeats the purpose of using a computer). Instead you define a model of a window, that is going to respond properly to you as you interact with it. Then you instantiate your window. You define things such as the size, number of panels, etc. Now, you have to make sure the window interfaces properly with the rest of the software. Now imagine that you want to change the colour of the window. In real life, you grab a pail of paint and you paint it. Don’t like the colour? You gotta wait until the previous paint dries, remove the old paint, and apply the new colour. In software? Well, if your window doesn’t define a way to specify a colour, you add support for that: If your abstraction model doesn’t define colour, well, you create the colour abstraction. You write this in some file (or files), and add these to your project. Then you build your software, and watch it render your window in the colour you specified.

Now, you can place windows everywhere you want in your software by re-using the same code you wrote for one class of windows. In a real house, you have to buy (or build) a new window each time you want to see through a wall.

Debugging a building? Don’t try this at home.

In your real-life window, if you don’t see through your window properly, you’ve gotta clean it, or turn on a light, or draw the blinds, etc. All that’s built-in for your. It’s physics.

Your software window doesn’t show through? Maybe you forgot to add another abstraction (or illusion) of what it was supposed to show. Or it’s interacting with other abstractions in a way you didn’t foresee. Or it’s not interacting with the hardware (the physical part of a computer) it’s not prepared to deal with. Or the other abstractions written by other people don’t interact with your window the way they’re supposed to. The list goes on. What’s worse? It’s very rarely the computer’s fault. It’s either your fault, or other person’s fault. The people that programmed those features didn’t do them the way were supposed to, or didn’t think of certain possibilities, or had another cascade of problems that led them to do things the way they did.

And just like in real-life (tangible, touchable life), when you fix something, you can break another. A short intro into the so-called art of testing.

Testing in real-life requires a person (or a number of them), to physically interact with each instance of an object (thing) to verify it behaves properly. In artificial life, you write even more lines of code that creates (or instantiates) objects. Then you write more lines to push buttons in these objects and see if they behave properly. You check the result by looking at strings of ones and zeroes. Or better yet, tell the machine to find certain patterns in the strings of ones and zeroes.

Finally, where am I going with this?

Once something physical is built, changing/replicating/updating it takes some considerable amount of time and resources. It’s easy to see and understand why.

Once a piece of software is written,

Replicating it is a matter of copying it. It’s like photocopying a document, except that it’s an exact replica of the original. You cannot tell the original and copy apart. The number of copies just depends on the amount of available hard drive space.

Changing or Updating it is a matter of editing a handful of files. Then you build it again. Let the computer crunch (transform the string of bits into another string of bits).

I’m sure a number of you will disagree with me here. I can hear the “It’s not quite that simple”. Actually, it is. If in your case it isn’t, you’re doing it wrong. You’re placing yourself in the middle of a process where a machine is perfectly capable of handling. If you don’t trust the machine to do something for you, that’s a different story.

So if building software is so much faster than building real things, how come we’re always wrong about the time it takes?

Because when we’re building real things, you are in direct contact with them. In software you are at least one level of abstraction away from the thing. You are defining a very specific set of instructions on how to build something. You are not grabbing a hammer and hitting on a nail. Rather you are telling a machine to grab a hammer, and nail, and giving it instructions on how to push the nail in. As an exercise for all the skeptics, try writing a system to do just that.

Now, try to imagine the effort required to tell a computer how to do all the hundreds of different tasks required to finish anything. The optimistic will say it’s not that much. The pessimistic will say it’ll take forever and a little more. The optimistic will be late. The pessimistic won’t even start.

We have been living in dwellings for as long as we can remember, so we had a lot of time to perfect the art of building them safe, sound and in time. Though, I hear in civil engineering and architecture, projects often end up late. If creating software is the equivalent to a meta process for building houses, for example, no wonder all projects are always running late.

Under the hood

Another comparison I hear often is to compare a code change (e.g. required by a new feature) with working on one’s car engine. Once the developer is in the middle of something, he will try to explain to his manager that nothing is building because the engine is out, and all the tubes, pipes, wires are disconnected, etc. The guts (pun intended). The manager gets it, because she has seen her car like that, and she knows she can’t go anywhere if the engine is not able to start. That’s a fallacy. It’s so obvious it’s hard to explain.

How do we estimate tasks?

It’s all guess work. No matter how we sugar coat it, and how many project management books on software engineering we have read, or fancy tools, it’s all guess work. The truth is that we don’t know how long it will take to build some software because we haven’t built it yet. As a matter of fact, the last sentence should read as follows.

“The truth is that we don’t know how long it will take to write a piece of software because we haven’t written it yet.”

If you want to know exactly how long it takes to write anything, you have to write it. Then it becomes paradoxical, because once you have written it, the estimate is no longer necessary.

Since we don’t have all the time in the world, we try to short-circuit that process by guessing. We estimate the effort of a task by basing it on other similar tasks we have done in the past. These are some of the factors that influence our guess work.

Requirements (or how we interpret them)

If we could transmit our exact thoughts from one human to another, we wouldn’t need requirements documents. So in a project that involves many different people, that thought synchronization is vital, but it only happens with experimentation. We build something, show it, and let the user try it. If what we wrote is what the user wanted or better, all is good. Otherwise, we have to “synchronize” requirements again, rinse and repeat.

The APIs and tools we rely on

Marketing does a great job of promoting how easy it is create software with a particular software library. The complexity of any software we write today has been greatly reduced by being able to re-use someone’s work through a software library. However, it doesn’t always behave as expected (or understood), and we tend to spend time learning the ins and outs of the diverse components and tools we use in our trade.

Mood

Ask any developer to estimate how long is something going to take when he’s on a roll. If he’s having a great day, squatting bugs, getting everything done perfectly and feeling great, he’ll underestimate the effort. Ask him again when he’s having one of those days that he couldn’t submit a single line of code because everything has been failing on him, and he may not even give you the time of day.

Unconsciously relying on our real-life schemas

When we think about features we wrote in the past, that are similar to what we’re trying to write now, we tend to remember only the time spent coding. By coding, I mean the time we spent typing the code. That’s a real tangible measurement of time. We were in front of a machine, typing. It’s easy to measure. Try to measure the amount of time you spend thinking about something, or finding a solution, and you’ll realize it’s a number of times more complicated, and you won’t remember it so easily. That’s because the amount of time spent typing code is what we find like brick layering. You’re placing one brick (compilable token) at a time, aligning it, making sure it’s the right one, etc. The estimate however, should be on all the effort taken to get to that point, plus the typing time, plus a margin for error.

As we’ve stablished before, that’s not a good comparison, hence the optimistic estimates.

The due date

We tend to think backwards from our goal. This is perfectly rational. We are given a goal, and an end-date. It’s natural to think that we are going to try to fit all the features we can in that amount of time. We don’t know how long it’s going to take to write it, because we haven’t written it yet. But we are usually optimistic we can do it in that amount of time. We are also afraid the task, which we really want to do, may be given to someone else, which will accept it for the same or less time and money.

Technology and its pace

The pace at which software and technology is currently evolving is remarkable. The common person has been living with software in our day-to-day lives for about 20 to 25 years. Software has come a long way in this time, and it seems that it has only scratched the surface of what’s possible to do with it. Software professionals have to keep up with this pace to remain competitive, and that means constantly staying to on the lookout for how to do things more efficiently, learn new technologies, and more.

However, users are not always at the latest and greatest, so software has to be written to accommodate shortcomings from the past and the future, different types of users, different legislation, and the list goes on forever. If we try to predict all these factors while estimating a software project, we run into another paradox: You can’t provide something for a user to try because you don’t have it yet. The user can’t tell you exactly what they think or want because they haven’t seen it yet.

Interrupts

We never take into account all the time required to perform other small tasks during a project’s lifetime. We help other people, answer questions, ask questions, provide builds, participate in meetings, read and write documentation, and a million other small things that eat up time. At the end of a year-long project, these seemingly small events amount to a sizeable amount of time. The problem is that every time an interruption occurs, getting back to the frame of mind we were requires some ramp-up time. That time is never taken into account (and it’s not easy to do so). That must be why many of us are night owls, when no one else is around.

Research (or lack thereof)

Often times we think something is straightforward to do, only to realize later that we need to research how to do it. Sometimes, that is a key part of the software we’re developing, but the entire project has to be put on hold, since a key assumption wasn’t valid: We didn’t know how to do something. That can throw a project’s estimate out to about infinite effort, if the problem is impossible to solve.

Many image processing algorithms require an image’s gradient vectors (for example, from the output of a Sobel operator). I came across this particular one which uses gradient vector angles to find symmetrically opposing vectors. It quickly became evident that it would be CPU intensive to use the atan2 function. Moreover, atan2‘s output is an angle between -180˚ and 180˚ degrees. I needed an angle from 0˚ to 360˚.

For readability and portability purposes using atan2 is not a problem, given that one might have a CPU with many really fast cores. But here’s the catch: implement it for a smartphone continuously analyzing images from the phone’s camera.

Analysis

First I looked at creating a cache of the atan2 values, as they were computed (lazy evaluation). I discarded the idea since it is complex, eats up memory quickly, and becomes slower as the data set grows.  I then analyzed the algorithm’s input domain, and realized it is really limited.

Smartphone cameras usually output images in the 32-bit RGBA or 24-bit RGB formats. These images are converted into grayscale 8-bit images for gradient vector computation. Thus, the input data for this problem is two 8-bit grayscale images, each representing the X and Y gradient vector components, where each vector component is 8 bits wide (between -128 and 127).

vector angle using atan2

The traditional implementation calls for the following implementation.

unsigned short angle;
angle = atan2(y,x);
if(y<0) angle += 360; /* adjust angle to [0,360]. */

The solution

array lookup

Pre-compute all the angle values! I created a script sweeping across all possible input values, outputting an array with 256 x 256 = 65536 entries as header file. Each entry in the array contains the angle given by atan2(gy,gx). To store an angle with two digits of precision, we can use a 16-bit unsigned integer to conserve memory and take advantage of fast integer operations (as opposed to floating point). This array requires 128KB of memory (65536 entries with 2 bytes each). That’s not very much memory in a modern smartphone.

Finding a vector’s angle then becomes as simple as an array lookup:

angle = vector_angle[ (gy << 8) | gx ];

Where gx and gy are the gradient vector X and Y components, and 8 bits wide.

Bonus side-effects

The curious reader will realize the input value range is asymmetric. There are 127 positive values and 128 negative values, and one zero (for a total of 256 values). If we’re trying to use these angles to find perfectly symmetric vectors, we need to be careful with the tolerance between the two opposing vectors. That requires extra CPU cycles.

However, pre-computing vector angles gives us a way to ensure the input is such that for any angle there’s an exact opposite angle (e.g. for 78.91º there will be 360º-78.91º = 281.09º). I did that by ensuring I had two values for zero (0 and -1). That way, -128 becomes opposite to 127, and so on as shown in the table below.

Experimental Results

Mean error

I validated my approach by calculating the mean error between the “cached” angle and the value given by atan2. Each and every angle for vector (gx,gy) where gx and gy belong to [-l,l] is computed. As expected, the error for any l≤127 is 0.

Note: to be precise the range would have to be [-l,l-1] and l=128, but I use [-l,l] for simplicity.

For l>127, it’s necessary to normalize any vector with |gx|>127 or |gy|>127 to the [-l,l] range, so we can perform the array lookup. I chose to bitwise right-shift both components 1 bit, until both gx and gy are within the [-l,l] range. We can see from the table below that it’s safe to use the array lookup approach for angles with up to 2 digits of precision,  when gradient vector component values are within the [-1000,1000] range.

Time results

I compared the performance of the array lookup approach against the traditional atan2 approach, by measuring the time that it takes to sweep the finite set of gradient vectors in the (gx,gy) domain, where  gx and gy belong to [-128,127]. I simulated the same experiment as if a number of images were analyzed (each image corresponds to 1 iteration). The table below shows the array lookup method is about 10 times faster than the traditional atan2 approach.

Moreover, as previously shown, some angles can be outside of the domain required by the array lookup approach. I have measured the performance of sweeping across the domain (gx,gy) where gx and gy belong to [-1000,1000]. In the case of atan2 I have applied the values gx and gy directly, whereas in the case of the array lookup I have reduced each vector (gx,gy) to a known domain by shifting right both components 1 bit, as explained above. The table below shows that the array lookup approach still is 2 times faster than employing atan2.

Future work

There’s room for improvement in the normalization of arbitrary vectors to the known array lookup input domain. My implementation is rather simple, and I believe one can improve it so the performance will be much closer to 10 times faster than the atan2, rather than twice as fast.

Ingredients and Implements

This is what you’ll need:

1. A Couscous steamer, or a 2-stage vegetable steamer. Here’s mine (an Authentic Brazilian Couscous Steamer).

It has three parts: the shell, the steamer grate, and the lid.

2.Pre-cooked polenta. My wife and I like Divella‘s Polenta Instantanea, from La Bottega Nicastro.

3. Un-sweetened shredded coconut.

4. A soft cheese, like Havarti or Cheddar.

5. Salt

Preparation

1. Fill half the bottom of the steamer with water (as shown above), replace the steamer grate.

2. Mix 1 cup of the polenta with a 1/4 cup of shredded coconut and about a 1/2 tablespoon of salt (or to taste).

3. Mix well. Then add a 3/4 cup of water, and mix until thoroughly moist.

4. Fluff with a fork or spoon until dry ingredients absorb all the water.

5. Transfer half the couscous to the steamer, and top it with thin slices of cheese. Push on it gently with the back of a spoon to pack the couscous a little.

6. Transfer the rest of the couscous to the steamer. Pack the couscous a little.. Top it with more cheese.

7. Close the steamer and cook it on medium-high (position 6 out of 10 in our stove)

7. Cook until the cheese is bubbling and the wonderful scent of cooked polenta comes out. Serve immediately.

Cut into quarters or eighths. Spread some butter (which melts and adds a flavour), or top with cottage cheese, or just eat as is. It’s delicious any way!

If you live in Canada, you’ve probably seen a TV show called Dragon’s Den. For those of you who never heard of it, it’s a show where a panel of 5 investors listen to business ideas from people seeking capital to take their idea or business to the next level. The format is very straightforward: Candidates ask for a certain amount of money in exchange for a percentage of their business. These candidates would use the cash to grow the business, so both them and the investors share the risks and the profits.

As part of the Ottawa Startup community, I think it would be awesome if we had a “Dragon’s Den with Human Capital” show. I call it Leader’s Lair. We have lots of technology talent in this city (including myself), and many of us are trying to start our own thing. However, it’s hard to move a mountain by oneself, and many times, one just needs a hand, not employees.

The Pitch

Create a web-based show (Leader’s Lair) with a similar format to Dragon’s Den, where, instead of money, the currency is Human Capital!

Let me explain: Money can buy things and pay for people’s time. That’s wonderful. However, I find (and I’m sure many of you do without even realizing it) that to get where you want to be, you need another type of capital: Human Capital.

Human Capital can give you feedback, connect you to the right people, show you the ropes, and most importantly, care.

Most Leaders I have met through the Startup Ottawa community want to share their experiences. So much that they take the reigns of our very own “Ottawa Start-up Community” and keep it alive and kicking. It’s a lot of work, for really no compensation. It’s fantastic! They do it because they care. Unfortunately these people become really busy and sought after. Naturally, the amount of feedback, connecting, showing, and caring towards any of us tends to zero rapidly.

We can bridge this gap and have fun doing it. How? Read on.

Leader’s Lair, the show

An innovator presents her business idea, and offers a part of her start-up business in exchange for a Leader’s expertise, in front of a panel of 5 Leaders. Examples:

• I need Business expertise – Where is the money in my idea?
• I need Marketing expertise – How to make my idea appealing?
• I need Sales expertise – How to price and sell my product or service?
• I need Execution expertise – What do I need to make this idea happen?

Discussions between Leaders and the innovator is encouraged. If a Leader finds the idea is interesting, he can offer his expertise as a commitment (e.g. half a day of his marketing expertise every two months), and negotiate the terms (e.g. for 5% of the profits for the first year). If the idea is of no interest to him, the Leader should explain why to the innovator.

The commitment from a Leader to an innovator keeps the communication channel open (helping her succeed with expert advice). And the promise of something in return from an innovator to a Leader is an added incentive for him to care, which leads both to success!

Call to Action

The concept is pretty simple. A couple of cameras, a panel of committed Leaders, movie editing software, an internet connection, a handful of wannabe innovators, perhaps even a volunteer M.C., and we have a YouTube show worth watching.

Are you in?

Execution, execution, execution

You can have a million dollar idea. If it doesn’t leave your head, it’s worth nothing. It’s that simple. Like many people, I had the misconception that they are ought to get me: Other people are out there to steal my ideas, screw me over, climb on my back, and then sue me. Ok, perhaps not quite as dramatically, but you get the point.

My advice: talk to people. If you have an idea, share it. There’s people out there willing to listen, to give you advice, to help you, and best of all: waiting for you to execute on it, so they can use it!

Most importantly, when you try to execute your idea you will realize why execution is so much more important (and difficult) than the idea itself. Thomas Edison had realized this way back (1% inspiration vs. 99% perspiration).

Network

Ok, so executing your idea sounds wonderful right about now. I learned that part of the execution is to share the idea and listen to feedback. Who is willing to listen to your idea?

Like-minded people.

Find working groups of interest to you. Join mailing lists, start a blog, get a twitter account, listen and be heard. Surround yourself with peers that want to achieve similar goals.

That became the one of the main reasons I kept going to TeamCamp. First I got to know the venue, The Code Factory. Quickly I learned about all the birds-of-a-feather groups and meetings taking place in the region. Then lots of well connected people connected me with other well-connected people. Someday, I hope I’ll be as well connected, and pay back the favour.

The power of examples

Winter was starting to settle in. It was still one of my first TeamCamp meetings, and many new faces were present. We weren’t discussing any particularly interesting topic amongst techies, so there was almost a look of apathy on everyone’s face. We turned to the second half of the meeting, where John Nash wanted to talk about something he had built on his spare time. He didn’t have a fancy presentation. He just did a brief introduction, a demo, and suddenly it clicked. The look on our faces changed immediately. On all of us. On another meeting about how to present to customers, months later, Allan Isfan reiterated the same concept.

I have no scientific evidence of this, but it’s easy to observe the empirical evidence. It’s much easier to explain something when you see it working rather than to talk about it. A mock-up, a very simple implementation of a concept, that’s all it takes.

MVP

No, not Most Valuable Player, but rather Minimum Viable Product. Since you’re building a demo version of your idea, why not think about the absolute minimum you need to get it in front of customers? Fact is, MVP is so simple, it doesn’t need further explanation.

The MVP will allow you to get feedback quick, and show it to potential customers. It will also provide some insight into how difficult it’ll be to implement the full-featured product. It may also help you land the first customers, which can help fund the second round of implementation and so on.

It’s been a great ride, and I’m looking forward to the next year of TeamCamp.

Well, a few Google searches later, and guess what? I could find great sites on Q.C., such as Sam’s Quartz Composer blog, but nobody processing images with Q.C.

What I needed was a Core Image Filter to calculate the Mean Square Error (MSE) between two images. Sure, Q.C. didn’t have one out of the box, but that was easily fixed by using a generic GPU-accellerated Core Image Filter. This generic Core Image Filter is based on the CIKernel language (a subset of the OpenGL Shading Language, OpenGLSL). That was all the code I had to write. About 10 lines of C-like code, and a tiny amount of javascript (mostly modified from the Core Image Filter template).

Then I used an averaging filter, to compute the average of the square error. Tada! There I had my MSE calculator. Re-factoring was a bliss, by simply selecting the MSE boxes, and clicking on “Create Macro”. That selection became a box with its own inputs (original image, estimated image) and outputs (each component of the averaged pixel). Sweet, really sweet!

But, this still doesn’t close the gap to this post’s title. How do we use Quartz Composer as an Image Processing tool? Well, it can be employed quickly as an Image Processing lab. For example, I created a patch to compare two images, side by side, taken with the Mac’s built-in camera, where you would compute the MSE between the images.

The original image is stored on the left-hand side. Every time the user left-clicks on the Viewer window, the original image is updated. The estimated image (camera’s output image) is shown on the right-hand side, masked with the original image. At the middle bottom of the viewer there is the computed MSE. This lab allows you to develop your image processing algorithm, and see that it works before trying to code or optimize it.

To play with this small lab, download the Quartz Composer file.

Please comment if it this helps, or if have other cool patches or filters in Quartz Composer to share.

What you will need

• A WordPress blog
• Apple’s Automator
• OttoMate – Web Test Automator Actions
• Be logged in to your blog

The workflow

The workflow to back up  your blog is pretty simple. Once it’s setup, all you need is to run it.

1. Ensure you have the OttoMate actions installed in your /Users/<username>/Library/Automator
2. Create a new Automator Workflow.
3. Add a variable called “Blog Export URL”, and set its value to http://<mywordpressblogdomain>/wp-admin/export.php
4. Add a “Get Value of Variable” action to the workflow, and select the “Blog Export URL” variable.
5. Add a “New Safari Documents” action. That will open a new Safari window pointing to the “Blog Export URL”
6. Add an OttoMate “Click Link or Button in Current Page” action
   1. Select “HTML button” and “text” in the drop down widgets.
   2. Type “Download Export File” in the text field. Note: If your WordPress installation is in another language, enter the appropriate text for that button.
7. Add a “Pause” action, to allow Safari enough time to download the blog XML file.
8. Add a “Find Finder Items” action to find the wordpress XML file in the Downloads folder.
   1. Select the folder where downloads go (by the default they go into the “Downloads” folder).
   2. Set the file filter. In my case, I wanted files that start with “wordpress” and end with “.xml”
9. Finally, add a “Move Finder Items” action to copy the files selected by the previous action, to their destination location (“/Users/<username>/Documents/…/blog backups” in my case).
10. Run the workflow, and watch it back up your blog.

Notes:

• WordPress export does not export media. Keep a copy of the media you push to your blogs.
• You should program Automator to run your wordpress backup action periodically (say every day, or twice a day).
• You still need to close the safari window after the backup, since there doesn’t seem to be an action to do that. If you know one, please comment.

May happen soon

1. Amber MacArthur, from CommandN and net@night. Her shows are awesome, and through her I became a fan of The Guild, with Felicia Day.

May happen some day

1. Tim Harford, author of The Undercover Economist, and The Logic of Life.
2. Leo Laporte, the Tech guy. Big fan of his show.
3. Sarah Lane (maybe Martin Sargent?) from This Week in Fun. At first she seemed to be like an extremely high maintenance chick. But now I enjoy the TWIF show in almost a masochistic way.
4. Andy Ihnatko, just ’cause he seems like a fun wacky guy.

Will probably never happen

1. Steve Jobs, CEO of Apple. I wouldn’t know what to tell him, especially after what I heard on TWiT 212. I give him money, he gives my great products. Let’s leave it at that.
2. Steve Wozniak (the Woz) (In fact I rubbed shoulders with him when I went to hear him speak on Aug 19 2009, at the Brookstreet hotel in Kanata, Ontario, Canada).
3. Eddie Vedder, the voice behind Pearl Jam.
4. Stephen Fry, Comedian, Author and active twitterer/blogger.

Famous People I could have met

1. Donald Sutherland. We shared a flight from Toronto to Washington, DC one time.
2. Bob Rae. Got into an elevator with him at the Ottawa airport.

I could go on and on, but there is a catch: the what.

Knowing where to be is the easy part to figure out. If it were the only step necessary, I think there would be many more happy people in the world. Unfortunately the what, and effectively the how are what’s keeping me from getting to where.

But there’s hope, and that’s why I’m starting this blog. This hope is what’s driving me towards finding a solution, or better, a problem, in which I really believe I (and those surrounding me), will find a profitable solution for customers and for myself (and my team). A kind of a win-win situation, where I can contribute and live off it.

Since I’m the CEO (Chief Everything Officer) of my life, I took the executive decision to blog about my goal, in the hope that I can help the community as much as the community can contribute towards achieving my dream.