Does UX design have a good future?

Yes and no. The label “UX” may fall out of fashion or become permanently and unhappily glued to UI in “UX/UI”, but don’t worry about the label. Worry about the skill set. The skillset will still be needed a hundred years from now.

The label itself, “UX”, is so badly abused now that it’s practically meaningless. Depending on who’s writing the job description, it could mean any number of things:

  • Person who takes requirements and makes wireframes for the graphic designers.
  • “Hey, we need a button on this page, what color should it be?”
  • Web designer who also writes the front-end code.
  • Graphic designer.
  • Person who makes the mock-ups.
  • Person who breaks the tie when stakeholders and developers disagree on what’s more “intuitive”.
  • Person who slows down development by asking for things that are more difficult to code.

The full scope of user-experience design, however, is the — you guessed it — entire user experience. It’s not a little value-added widget stamped “UX” you just bolt on to the product to make it more “intuitive”.

As a UX designer, you need to be competent in usability and ergonomics but also the emotional effect of the design, primarily but not only aesthetic design. You must be a competent interaction designer and information architect, and you must know how to validate your design choices with usability or A/B testing and other real-world methods. You don’t necessarily need to be a graphic designer, but you do need to know how to evaluate a design aesthetically. You don’t necessarily need to be a writer, but you do need to know how to evaluate labels and copy. You don’t necessarily need to have a degree in business, but you do need to understand how to balance business objectives, resource constraints, and user needs.

If you have that competence, you are a valuable asset to any product regardless of your label. It means you can affect outcomes like customer satisfaction, sales, retention, error rates, customer-service calls, and brand perception. Importantly, that competence is not specific to any technology. It’s not “Web UX” as opposed to “mobile UX”. It’s a good design optimized for people, context, and goals.

Be a designer, not a label, and your future will be just fine.

Why Is It Fashionable & Trendy To Hate Documentation:

Every time there is a discussion about the software development life cycle, developers and project managers are divided into two camps: Waterfall vs Agile.

Since Agile has somehow positioned itself as ultimate cost-saver by validating frequently and delivering early, documentation has taken a backseat due to it being the primary ingredient of waterfall model.

Besides, it appears to be adding no tangible value to the end-user.

Efficient coders publicly hate documentation. They discuss the design in team meetings. They will fill up a whiteboard in 3 minutes. But they won’t document.

But their reasons for hating documentation are sometimes creepy.

More often than not, rockstar developers are fearful of putting their take on a design decision in a document. A document that can some day come back and haunt them.

They publicly advocate and demand they jump on the real thing, instead of wasting ePaper.

And junior developers simply idolize them.

The fact is: every super-efficient coder professing great hands-on has considerable documentation under his / her belt. It could be scratchpad notes in trash cans, or whiteboards rubbed a million times.

He / She is simply reluctant to admit it publicly.

What Makes Documentation The Crucial 20% In Development Pareto?

Pareto states:

20% of the invested input is responsible for 80% of the results obtained

If you had to sharpen your axe in software development, documentation is your tool to sharpen that axe.

20% time invested after documentation can be transformed into effective and smooth development during 80% of the SDLC time.

This is because documentation gifts you with the most crucial asset: Time to think over the solution.

It’s the same thing that you do while taking a shower, in transit, or making your morning coffee.

Documentation can take the cognitive output of those tasks one level further and solidifies the mental sketch of features to develop.

You are already doing it every day on scratch pads and whiteboards, in the form of block diagrams, flowcharts, and notes.

Your Documentation simply ensures:

  • You do it in a sophisticated way
  • You make it sharable with colleagues — both present and future ones
  • You create a snapshot of your team’s development activity at a specific time. Future teams can go back to that snapshot any time, and make revolutionary revivals possible, just like renaissance did of Greek and Roman art.


Documentation has powered ISO certified product companies that run today’s world including Boeing, Lockheed Martin, and NASA.

Documentation is underrated in today’s Agile world. However, all tools surrounding Agile have great offerings in documenting. Let’s bring back the documentation before robots start writing better programs and overpower us.

What are the expectations of a UI architect?

First, you are designing the user experience (UE), not just a UI. You want to know your audience; expert, in-house, public, or a combination. For the public, you want to understand your target audience; perhaps some demographics like age and education. What is the goal of the site/app?

Second, designing a UI does not happen in a vacuum. It needs to interface not only with front end aspects like OS, browser, etc. but also with potential items like databases, external inputs(location, movement, etc) You need to be aware of those parameters so as to avoid creating a disaster for the team behind you. You are a member of a team!

Third, you need to understand what can be (reasonably) done within the architecture you are using. This is very much a balance issue, i.e. is it worth the development time vs the return or would something simpler fit the bill just as well.

Fourth, you need to interface with the client/ end users. You are both a translator and a communicator between the user and the programmers. To the third item above, the client may give you a list of things but they may not be willing to invest the money or potential launch delay to implement one or more of those items.

Unfortunately, I see more poorly thought out UI’s today than previously. For example, I critiqued a website recently that had fantastic programming with all the latest widgets. Very modern and geared toward twenty-somethings. The problem is their target audience was 45–65; a group that probably closed the tab within 15 seconds. Or seeing an expert POS system where the employee had about 50 mouse clicks to complete one screen. Had it been keyboard-driven, it would have taken about 1/3 the time.

Those were two bad user experiences where the architect just forgot the mission and didn’t consider the target and goal. Or maybe failed to ride herd on the team. Riding herd is a good skill; it isn’t so much that every member of the herd has to be in an exact position, but the herd needs to keep moving in the right direction and keep those strays closer.

I love software.

The more complex the better! What makes other programmers turn away in disgust is simply fascinating to me.

What interests me about technology is its significance as an artifact of human thought.

I’m really into the human factors of complexity theory. I’m really into systems thinking. I’m really into organizational behavior and cognitive biases. Code is interesting to me not because it is good or bad, elegant, or abstract, but because it is a manifestation of how people see the world, what assumptions they make, what associations they create.

Data Structures for Frontend Software Engineers

It’s more than just style…

Now, in addition to having an aesthetic understanding of HTML and CSS, Frontend Engineers are expected to master JavaScript as well. As datastores on the client become “replicas” of databases on the server, intimate knowledge of idiomatic data structures becomes pivotal. In fact, an engineer’s level of experience can be inferred from his or her ability to distinguish when and why to use a particular data structure.

Bad programmers worry about the code. Good programmers worry about data structures and their relationships. — Linus Torvalds, Creator of Linux and Git

At a high level, there are basically three types of data structures. Stacks and Queues are array-like structures that differ only in how items are inserted and removed. Linked ListsTrees, and Graphs are structures with nodes that keep references to other nodes. Hash Tables depend on hash functions to save and locate data.

In terms of complexity, Stacks and Queues are the simplest and can be constructed from Linked ListsTrees and Graphs are the most complex because they extend the concept of a linked list. Hash Tables need to utilize these data structures to perform reliably. In terms of efficiency, Linked Lists are most optimal for recording and storing data, while Hash Tables are most performant for searching and retrieving of data.


1. Design for the users and their tasks

Isolation does not work for interactive computer systems since they have to support those using them to perform what is required. Centered for support to the users which is key in making them user-centered and task-oriented. During development and this includes the whole period, it is important for the developer to consider the characteristics of the user population, the tasks involved in the real world and the specified environment.

2. Maintain consistency

The users need a system that is easy to learn with minimal and understandable requirements. The behavior of interface elements should be consistent. In fact, consistency will start at the designing phase so as to integrate with the existing components in a computer system. You can have a new design approach to counter interaction but what is most important is for you to look at how well it contributes to consistency issues. This will determine how users will view your approach and the time taken to learn.

3. Use simple and natural dialogue

The core application of a system should be incorporated with proper interaction to enable a dialogue with the user. The user should see only the relevant information that is essential for task completion because each time irrelevant information is added, it puts the user in a more complicated situation. It is advisable for the developer to use plain English and use vocabulary that is relevant to the targeted audience. Define the terminology so that it carries the same meaning.

4. Reduce unnecessary mental effort by the user

Users like to concentrate on the task at hand and worry less or not at all of the tool and its interaction with the designed application. They are more frustrated with complicated interaction with the computer or any other mobile device compatible with the application. Why? They are distracted from the main work.

Too much effort invested in learning the operation part makes them less efficient and prone to errors. This can certainly cost a business that heavily relies on the outcome of a task. The frequency of tasks is necessary since users don’t have to memorize information from a previous part of the system that is to be used in the next part. Instructions on how to use should be clearly defined and can be retrieved when needed.

5. Provide adequate feedback

Users need assurance that their actions have been successfully executed. This can be made evident by a change in appearance when completion is achieved successfully. If it takes longer, an indicator is useful to show that processing is still in progress, and this keeps the confidence of a user in shape. What is kept away is the information providing status about the internal affairs of the system.

Various levels of interaction should be backed up by feedback. At a lower level, confirmation can be received when a control operation is successful. A good example is a button appearing somehow pressed in to indicate that the user has already pressed it. Long operations can be verified by the system upon completion.

6. Provide adequate navigation mechanisms

Users being able to navigate with ease are another vital principle for them to know their position. This is made possible by the application of an efficient and consistent mechanism that assigns titles to the current windows and use of indicators like page numbers and bars for scrolling. Other things that can be included are an overview, history of visited areas and a navigation map.

You need to provide clear routes between the different windows that the user is engaged in. The form of provision should be appropriate for the user while at each stage of the intended task.

Sometimes, users can find themselves in areas that they do not intend to be in. There should be a clear emergency exit that can be used to leave an unwanted state without having to go through it like a Cancel button.

7. Let the user take charge

The user knows what he or she needs, and the developed system provides the solution. For the user to do what is required, they should be able only to take what is required and leave the rest to support an individual request. Constraints evoked by the system should as minimal as possible which prompts the developers to provide easy ways to achieve what is frequently needed.

8. Present information clearly

The arrangement of information is essential to the user while on-screen which enables the user to single out the different elements and data groups. This can be achieved by using boxes, spaces, and visual coding proficiency. Again, developers should not provide more than the necessary information to process a task.

9. Offer Assistance

A user should get all the help needed from a system with minimal use of the document provided. In other words, they should be self-explanatory. Information provided on the window should be in line with the user’s tasks. It is important for you to provide tooltips for icon-labeled buttons.

Online help should be related to whatever interaction is provided on the window. Task-oriented should be the tone with a list of steps to be followed.

10. Error-free

Minimize errors by directing the users towards the right way to achieve their goals. Feedback from users should be constrained to prevent error, were necessary to the task. However, this shouldn’t apply in situations that will end up limiting your users’ the choice in how to accomplish their tasks. Ensure that the system validates data entry as close as possible to the point of input.

Consider expressing error messages in plain language to avoid the use of codes, point out the exact problem, and offer a solution suggestion to the problem.

How to Maximize Usability

To maximize usability, you can employ iterative design, which gradually enhances the design through assessment from the early design stages. These steps enable you to incorporate feedback from the user and client until the system attains an ideal usability level.

The preferred approach for you to ensure usability is by testing actual users on an operating system. For you to achieve significant levels of usability, it necessitates you to focus on the design efforts for the specified system end-user.

Some of the methods to determine the primary users, how they work, and what duties they should accomplish, include user testing on system prototypes, a usability audit performed by specialists, and cognitive modeling.

Scrum methodology for non-technical people.

Scrum and most Agile methodologies are best-suited for projects with a high level of uncertainty.   In that kind of environment, an adaptive approach is needed to learn what works and doesn’t work as the project is in progress rather than trying to completely define a detailed plan for completing the project upfront.

That’s called an “empirical process control” approach.  The word “empirical” means “based on observation”; and, in the context of Scrum, it means that both the product and the process to produce the product are continuously adjusted based on observation to optimize both as the project is in progress.

Scrum is a process through which small teams work in incremental efforts to build large projects, focused on delivering demonstrable results at the end of every two-to-four weeks.

It’s also a method that supports teams to be more collaborative and take more ownership of solutions as they work on a project. This often results in team members feeling more engaged in the work and producing better overall results.

The basic steps of Scrum are:

  1. Gather a list of work that needs doing
  2. Find someone who cares to put it in priority order
  3. Set a time box to focus working on that list in priority order
  4. Do some work
  5. Inspect and adapt the work
  6. Inspect and adapt the process
  7. Inspect and adapt the list of work
  8. Go again

The Truth about Smart Contracts

Much like the words “blockchain”, “AI” and “cloud”, “smart contract” is one of those phrases that get a lot of hype.

After all, what can be better than being able to trust what will happen instead of using the judicial system? The promises of smart contracts include:

  • Enforcing contracts automatically, trustlessly and impartially
  • Taking out the middle-men in contract construction, contract execution, and contract enforcement
  • (By implication) Removing lawyers

I sympathize with the hype. After all, how much more efficient could things be if we could just remove the need for trusting the other party to execute?

What the heck is a smart contract, anyway? And isn’t that the domain of Ethereum? Isn’t this the way of the future? Why would you stand in the way of progress?

In this article, I’m going to examine what smart contracts are and the engineering reality that goes with it (spoiler: it’s not so simple and very hard to secure).

What is a Smart Contract?

A normal contract is an agreement between two or more parties that binds them to something in the future. Alice may pay Bob some money in return for use of Bob’s house (aka rent). Charlie may agree to repair any damage to Denise’s car in the future in return for a monthly payment (aka car insurance).

What’s different about a “smart” contract is that the conditions are both evaluated and executed by computer code making it trustless. So if Alice agrees to pay Bob $500 for a couch for delivery 3 months from now (aka couch future), some code can determine whether the conditions are true (has Alice paid Bob? has it been 3 months yet?) and do the execution (deliver the couch from escrow) without giving either party the ability to back out.

The key feature of a smart contract is that it has trustless execution. That is, you don’t need to rely on a third party to execute various conditions. Instead of relying on the other party to make good on their word or even worse, relying on lawyers and the legal system to remedy things should something go wrong, a smart contract executes what’s supposed to happen timely and objectively.

Smart Contracts are Pretty Dumb

The use of the word “smart” implies that these contracts have some innate intelligence. They don’t. The smart part of the contract is in not needing the other party’s cooperation to execute the agreement. Instead of having to kick out the renters that aren’t paying, a “smart” contract would lock the non-paying renters out of their apartment. The execution of the agreed-to consequences are what makes smart contracts powerful, not in the contract’s innate intelligence.

A truly intelligent contract would take into account all the extenuating circumstances, look at the spirit of the contract and make rulings that are fair even in the most murky of circumstances. In other words, a truly smart contract would act like a really good judge. Instead, a “smart contract” in this context is not intelligent at all. It’s actually very rules based and follows the rules down to a T and can’t take any secondary considerations or the “spirit” of the law into account.

In other words, making a contract trustless means that we really can’t have any room for ambiguity, which brings up the next problem.

Smart Contracts are Really Hard

Because of a lot of centralized marketing from Ethereum, there’s a mistaken belief that Smart Contracts only exist in Ethereum. This is not true. Bitcoin has had, from the very beginning in 2009, a pretty extensive smart contract language called Script. In fact, smart contracts existed before Bitcoin as far back as 1995. The difference between Bitcoin’s smart contract language and Ethereum’s is that Ethereum’s is Turing-complete. That is, Solidity (ETH’s smart contract language) allows for more complicated contracts at the expense of making them more difficult to analyze.

There are some significant consequences of complexity. While complex contracts can allow for more complicated situations, a complex contract is also very difficult to secure. Even in normal contracts, the more complicated the contract it is, the harder it gets to enforce as complications add more uncertainty and room for interpretation. With smart contracts, security means handling every possible way in which a contract could get executed and making sure that the contract does what the authors intend.

Execution in a Turing-complete context is extremely tricky and hard to analyze. Securing a Turing-complete smart contract becomes the equivalent of proving that a computer program does not have bugs. We know this is very difficult, as nearly every computer program in existence has bugs.

Consider that writing normal contracts takes years of study and a very hard bar exam to be able to write competently. Smart contracts require at least that level of competence and yet currently, many are written by newbies that don’t understand how secure it needs to be. This is very clear from the various contracts that have been shown to be flawed.

Bitcoin’s solution to this problem is to simply not have Turing-completeness. This makes the contracts easier to analyze as the possible states of the program are easier to enumerate and examine.

Ethereum’s solution is to place the burden on the smart-contract writers. It is up to the contract writers to make sure that the contract does what they intend.

Smart Contracts Aren’t Really Contracts (at least on ETH)

While leaving the responsibility of securing contracts to the writers sounds good in theory, in practice, this has had some serious centralizing consequences.

Ethereum launched with the idea that “code is law”. That is, a contract on Ethereum is the ultimate authority and nobody could overrule the contract. The idea was to make clear to smart contract developers that they’re on their own. If you screwed up in making your own smart contract, then in a sense, you deserve it. This came to a crashing halt when the DAO event happened.

DAO stands for “Decentralized Autonomous Organization” and a fund was created in Ethereum as a way to show what the platform could do. Users could deposit money to the DAO and get returns based on the investments that the DAO made. The decisions themselves would be crowd-sourced and decentralized. The DAO raised $150M in ETH when ETH was trading at around $20. This all sounded good in theory, but there was a problem. The code wasn’t secured very well and resulted in someone figuring out a way to drain the DAO out of money.

Many called the person draining the DAO of money a “hacker”. In the sense that the “hacker” found a way to take money from the contract in a way not intended by the creators, this is true. But in a broader sense, this was not a hacker at all, just someone that was taking advantage of the quirks in the smart contract to their advantage. This isn’t very different than a creative CPA figuring out a tax loophole to save their client’s money.

What happened next is that Ethereum decided that code no longer is law and reverted all the money that went into the DAO. In other words, the contract writers and investors did something stupid and the Ethereum developers decided to bail them out.

The fallout of this incident is well documented. Ethereum Classic was born, preserving the DAO as written and conserving the “code is law” principle. In addition, developers began shying away from using the Turing-completeness property of Ethereum as it’s proven to be hard to secure. ERC20 and ERC721 standards are the most frequently used smart contract templates in Ethereum and it’s important to point out that both types of contracts can be written without any Turing-completeness.

Smart Contracts Only Work with Digital Bearer Instruments

Even without Turing-completeness, smart contracts sound really good. After all, who likes having to go to court to get something that rightfully belongs to them trustlessly? Isn’t using a smart contract much easier than normal contracts?

For example, wouldn’t real estate benefit from smart contracts? Alice can prove she owns the house. Bob can send money for the house and get the house in exchange. No questions of ownership, trustless, fast execution by the machine, no need for judges, bureaucrats or title insurance. Sounds amazing, right?

There are two problems here. The first is that smart contract execution by a centralized party is not really trustless. You still have to trust the centralized party to execute. Trustlessness is the key feature, so centralized execution doesn’t really make sense. To make smart contracts really trustless, you need a platform that’s actually decentralized.

That leads us to the second problem. In a decentralized context, smart contracts only work if there’s some definitive link between the digital version and the physical version. That is, whenever the digital version of the house changes ownership the physical version has to also change ownership. There’s a need for the digital world to “know” about the physical world. This is known as the “Oracle problem”.

When Alice transfers the house to Bob, the smart contract needs to know that she actually transferred the house to Bob. There are several ways of doing this but they all have the same essential problem. There has to be some trust in some third party to verify the events in the physical world.

For example, the house could be represented as a non-fungible token on Ethereum. Alice could transfer the house to Bob in an atomic swap for some amount of ETH. Here’s the problem. Bob needs to trust that the token actually represents the house. There has to be some Oracle that ensures the transfer of the house token to him actually means that the house is his legally.

Furthermore, even if a government authority says that the token actually represents the house, what then happens if the token is stolen? Does the house now belong to the thief? What if the token is lost? Is the house not available to be sold anymore? Can the house token be re-issued? If so, by whom?

There is an intractable problem in linking a digital to a physical asset whether it be fruit, cars or houses at least in a decentralized context. Physical assets are regulated by the jurisdiction you happen to be in and this means they are in a sense trusting something in addition to the smart contract you’ve created. This means that possession in a smart contract doesn’t necessarily mean possession in the real world and suffers from the same trust problem as normal contracts. A smart contract that trusts the third party removes the killer feature of trustlessness.

Even digital assets like ebooks, health records or movies suffer from the same problem. The “rights” to these digital assets are ultimately decided by some other authority and an Oracle needs to be trusted.

And in this light, Oracles are just dumbed-down versions of judges. Instead of getting machine-only execution and simplified enforcement, what you actually get is the complexity of having to encode all possible outcomes with the subjectivity and risk of human judgment. In other words, by making a contract “smart”, you’ve drastically made it more complex to write while still having to trust someone.

The only things that can work without an Oracle are digital bearer instruments. Essentially, both sides of the trade need to not just be digital, but be bearer instruments. That is, ownership of the token cannot have dependencies outside of the smart contracting platform. Only when a smart contract has digital bearer instruments can a smart contract really be trustless.


I wish smart contracts could be more useful than they actually are. Unfortunately, much of what we humans think of as contracts bring in a whole bunch of assumptions and established case law that doesn’t need to be explicitly stated.

Furthermore, it turns out utilizing Turing completeness is an easy way to screw up and cause all sorts of unintended behavior. We should be labeling smart contract platforms Turing-vulnerable, not Turing-complete. The DAO incident also proved that there’s a “spirit” of the contract which is implicitly trusted and helps resolve disputes more so than we realize.

Smart contracts are simply too easy to screw up, too difficult to secure, too hard to make trustless and have too many external dependencies to work for most things. The only real place where smart contracts actually add trustlessness is with digital bearer instruments on decentralized platforms like Bitcoin.

Explain Bitcoin Like I’m Five

If you still can’t figure out what the heck a bitcoin is…

We’re sitting on a park bench. It’s a great day.

I have one apple with me. I give it to you.

You now have one apple and I have zero.

That was simple, right?

Let’s look closely at what happened:

My apple was physically put into your hand.

You know it happened. I was there. You were there. You touched it.

We didn’t need a third person there to help us make the transfer. We didn’t need to pull in Uncle Tommy (who’s a famous judge) to sit with us on the bench and confirm that the apple went from me to you.

The apple’s yours! I can’t give you another apple because I don’t have any left. I can’t control it anymore. The apple left my possession completely. You have full control over that apple now. You can give it to your friend if you want, and then that friend can give it to his friend. And so on.

So that’s what an in-person exchange looks like. I guess it’s really the same, whether I’m giving you a banana, a book, or say a quarter, or a dollar bill….

But I’m getting ahead of myself.

Back to apples!

Now say, I have one digital apple. Here, I’ll give you my digital apple.

Ah! Now it gets interesting.

How do you know that that digital apple that used to be mine, is now yours, and only yours? Think about it for a second.

It’s more complicated, right? How do you know that I didn’t send that apple to Uncle Tommy as an email attachment first? Or your friend Joe? Or my friend Lisa too?

Maybe I made a couple of copies of that digital apple on my computer. Maybe I put it up on the internet and one million people downloaded it.

As you see, this digital exchange is a bit of a problem. Sending digital apples doesn’t look like sending physical apples.

Some brainy computer scientists actually have a name for this problem: it’s called the double-spending problem. But don’t worry about it. All you need to know is that it’s confused them for quite some time and they’ve never solved it.

Until now.

But let’s try to think of a solution on our own.


Maybe these digital apples need to be tracked in a ledger. It’s basically a book where you track all transactions — an accounting book.

This ledger, since it’s digital, needs to live in its own world and have someone in charge of it.

Say, just like World of Warcraft. Blizzard, the guys who created the online game, have a “digital ledger” of all the rare flaming fire swords that exist in their system. So, cool, someone like them could keep track of our digital apples. Awesome — we solved it!


There’s a bit of a problem though:

1) What if some guy over at Blizzard created more? He could just add a couple of digital apples to his balance whenever he wants!

2) It’s not exactly like when we were on the bench that one day. It was just you and me then. Going through Blizzard is like pulling in Uncle Tommy(a third-party) out of court(did I mention he’s a famous judge?) for all our park bench transactions. How can I just hand over my digital apple to you, like, you know— the usual way?

Is there any way to closely replicate our park bench, just you-and-me, transaction digitally? It seems kinda tough…

The Solution

What if we gave this ledger — to everybody? Instead of the ledger living on a Blizzard computer, it’ll live in everybody’s computers. All the transactions that have ever happened, from all time, in digital apples will be recorded in it.

You can’t cheat it. I can’t send you digital apples I don’t have, because then it wouldn’t sync up with everybody in the system. It’d be a tough system to beat. Especially if it got really big.

Plus it’s not controlled by one person, so I know there’s no one that can just decide to give himself more digital apples. The rules of the system were already defined at the beginning. And the code and rules are open-source. It’s there for the smart people to contribute to, maintain, secure, improve on, and check on.

You could participate in this network too and update the ledger and make sure it all checks out. For the trouble, you could get like 25 digital apples as a reward. In fact, that’s the only way to create more digital apples in the system.

I simplified quite a bit

…but that system I explained exists. It’s called the Bitcoin protocol. And those digital apples are the “bitcoins” within the system. Fancy!

So, did you see what happened? What does the public ledger enable?

1) It’s open-source remember? The total number of apples was defined in the public ledger at the beginning. I know the exact amount that exists. Within the system, I know they are limited (scarce).

2) When I make an exchange I now know that digital apple certifiably left my possession and is now completely yours. I used to not be able to say that about digital things. It will be updated and verified by the public ledger.

3)Because it’s a public ledger, I didn’t need Uncle Tommy(third-party) to make sure I didn’t cheat, or make extra copies for myself, or send apples twice, or thrice…

Within the system, the exchange of a digital apple is now just like the exchange of a physical one. It’s now as good as seeing a physical apple leave my hand and drop into your pocket. And just like on the park bench, the exchange involved two people only. You and me — we didn’t need Uncle Tommy there to make it valid.

In other words, it behaves like a physical object.

But you know what’s cool? It’s still digital. We can now deal with 1,000 apples, or 1 million apples, or even .0000001 apples. I can send it with a click of a button, and I can still drop it in your digital pocket if I was in Nicaragua and you were all the way in New York.

I can even make other digital things ride on top of these digital apples! It’s digital after-all. Maybe I can attach some text on it — a digital note. Or maybe I can attach more important things; like say a contract, or a stock certificate, or an ID card…

So this is great! How should we treat or value these “digital apples”? They’re quite useful, aren’t they?

Well, a lot of people are arguing over it now. There’s a debate between this and that economic school. Between politicians. Between programmers. Don’t listen to all of them though. Some people are smart. Some are misinformed. Some say the system is worth a lot, some say it’s actually worth zero. Some guy actually put a hard number: $1,300 per apple. Some say it’s digital gold, some a currency. Others say they’re just like tulips. Some people say it’ll change the world, some say it’s just a fad.

What does a ScrumMaster do?

Here are three different ways I will try to concisely summarize the ScrumMaster role:

  1. As a ScrumMaster, your job is not to control the team or stakeholders or anybody, for that matter. Your job is to ask questions and make observations that will help lead people to their teachable moment. Whether they choose to learn or not is up to them but you must keep leading them there, every day
  2. Being a ScrumMaster is rather like being a mirror. Every day you are saying “Here is what I am seeing. What do you see?”
  3. Flow is the psychological state when working of being completely immersed in what you are doing. Flow is the most productive (and pleasurable) state in which to perform work. But many Scrum teams start life at the opposite end of the spectrum in a state called thrash. Thrash is that frustrating feeling that it takes 10 units of effort to get one unit of results. It is not a ScrumMaster’s job to manage the team or “make” them perform. Rather, it is his/her job to do everything in their power to move her team towards flow and away from thrash.