Minimum Viable Technology (MVT) — Move Fast & Keep Shipping

Article by –

Technology teams can be the biggest asset or worst bottleneck for a growing company based on the strategy taken by them. In name of future proofing engineering, the technology teams become a hurdle to company’s goals. You can see the ‘hidden frustration” in Bezos words below ..

Engineers should be fast acting cowboys instead of calm clear-headed computer scientists — Jeff Bezos, Founder & CEO, Amazon

Rampant Problem in Industry: When the task is to build a bike, the product and technology teams would plan for a product, which can later run on motor, seat four people, sail in sea and even fly in the future. This hypothetical building of castle in air, digresses the focus from the real problem to be fixed. This is what Bezos is suggesting to refrain from, as it wastes resources and agonising delays the time to market.

Being defensive, the Product/Technology teams usually build a cannon for killing a bird.

Minimum Viable Product (MVP) philosophy evolved, to avoid this “unnecessarily over-thinking and over-preparation” problem which plagued products in all companies. It encouraged building the minimum required at a certain point of time and then iterating and improving it going forward. MVP approach enables much needed fast experimentation, fail fast and invest where needed strategy.

No such philosophy evolved for Technology. Therefore, the decades old defensive and paranoid philosophy still prevails (which was much needed during older 1–2 year long waterfall releases). This becomes competitive disadvantage for startups usually fighting for survival or growing fast.

Fundamental problem is that the engineers blindly copy the large company’s strategies, considering them to be the standard. Corporate and startups differ widely on their needs of scale, brand, speed, impact of a feature, loss by a bug, etc. Startups enjoy more freedom to make mistakes and that they should exploit to their benefit.

Strategies used in big companies are more often irrelevant and even detrimental to a small growing company’s interests.

Minimum Viable Technology: The solution to above problems is to Build the Minimum Technology, that makes the product and its foreseeable further iterations Viable. Make it live a.s.a.p. and then iterate and improve it based on real usage learnings. Every company is in different stage of evolution. Something that is MVT for a big company, can be over-engineering for startups.

If the task is to kill a bird, we should build a catapult/small-gun to begin with. If that becomes successful and there is a need to kill more or bigger animals, then bigger-guns/cannons should be built as required.

There is nothing so useless as doing efficiently that which should not be done at all. ~ Peter Drucker

Startups experiment a lot and only a few of them sustain the test of time. As per 80–20 rule, only those 20% successful ones should get deeper technology investments.

Principles of Minimum Viable Technology (MVT):

  • Most decisions can be reversed or fixed easily. Choose wisely by bucketing the decision properly into reversible or non-reversible. And judiciously decide how much to prepare for that case. (Read Jeff Bezos’ two types of decisions).

It’s important to internalise how irreversible, fatal, or non-fatal a decision may be. Very few can’t be undone. — Dave Girouard

  • Build MVT — Fast & cost effective. Build the Minimum Technology that makes the product and their foreseeable iterations Viable. Side towards operational familiarity while choosing technology rather than falling of the latest buzzword (a sure sign of inexperience and not being in trenches before).
  • Embrace change with open heart — iterate and rebuild as needed: Never try to force fit newer realities into the older model itself. Be ready to re-factor or throw away and rebuild where justified.
  • Keep fundamentals right & a Rule of Thumb: It’s a fine line between under-engineering and MVT approach, that has to be tread properly. Fundamentals have to be well deliberated and clear. Don’t rush into execution without thinking completely, otherwise it will lead to more resource waste later. Thinking has to complete and deliberate choices must be there to cut scope. The rule of thumb, is  discuss the ideal solution on board and then decide what to take out of scope to make it MVT.
  • Speed and Quality can go hand in hand: Never justify the bad quality of your work by using the speed of execution as excuse.

MVT is for scope reduction, not for quality reduction.

  • MVP/MVT is applicable for every iteration/release: People relate MVP to the First release of product only. In fact, it applies to every stage. MVP/MVT needs to be chosen from the remaining next tasks at every stage. At no stage, it is ok to waste time and resources.
  • Deep understanding, conviction and confidence is needed for MVT. Both MVP and MVT approach is about taking bold calls like — “Out of these tasks, only this much is enough to win this stage of game”. While defensive traditional approach is like — “we can’t win or sustain if we do not do most of the known tasks”.

Move Fast. Keep Shipping!!

* The term “Minimum Viable Technology – MVT” is coined by the author.


Courtesy: LinkedIn

ChromeDriver Error : Unsupported major.minor version 52.0

Came across this error while trying to get Jenkins-Selenium combination running on my machine:-

org/openqa/selenium/chrome/ChromeDriver : Unsupported major.minor version 52.0

Solution: Found out I have given Selenium v3.0.1 in my pom.xml file, which is not a stable selenium version. Reverted back the previous most stable selenium version i.e v2.53.1. This resolved my logjam.

Comparison Query Operators

For details on specific operator, including syntax and examples, click on the specific operator to go to its reference page.

For comparison of different BSON type values, see the specified BSON comparison order.

Name Description
$eq Matches values that are equal to a specified value.
$gt Matches values that are greater than a specified value.
$gte Matches values that are greater than or equal to a specified value.
$lt Matches values that are less than a specified value.
$lte Matches values that are less than or equal to a specified value.
$ne Matches all values that are not equal to a specified value.
$in Matches any of the values specified in an array.
$nin Matches none of the values specified in an array.

How to remove an application completely from linux

  • apt-get remove packagename will remove the binaries, but not the configuration or data files of the package packagename. It will also leave dependencies installed with it on installation time untouched.
  • apt-get purge packagename  or apt-get remove --purge packagenamewill remove about everything regarding the package packagename, but not the dependencies installed with it on installation. Both commands are equivalent.Particularly useful when you want to ‘start all over’ with an application because you messed up the configuration. However, it does not remove configuration or data files residing in users home directories, usually in hidden folders there. There is no easy way to get those removed as well.
  • apt-get autoremove  removes orphaned packages, i.e. installed packages that used to be installed as an dependency, but aren’t any longer. Use this after removing a package which had installed dependencies you’re no longer interested in.
  • aptitude remove packagename  or aptitude purge packagename (likewise)will also attempt to remove other packages which were required by packagename on but are not required by any remaining packages.

And many more exist. Lower-level dpkg-commands can be used (advanced), or GUI tools like Muon, Synaptic, Software Center, etc. There’s no single ‘correct way’ of removing applications or performing other tasks interacting with your package management.

The list you found are just examples. Make sure you understand the meanings and try out what it wants to do before accepting the action (you need to press Y before it actually performs the actions as proposed).

The asterisk version in the question is probably wrong; apt-get accepts a regular expression and not a glob pattern as the shell. So what happens with

sudo apt-get remove application*

is the following:

  1. The shell tries to expand application* looking at the files in the current directory. If (as is normally the case) it finds nothing, it returns the glob pattern unaltered (supposing bashwith default behavior here — zsh will error out).
  2. apt-get will remove the packages whose name contains a string that satisfies the regular expression application*, that is, applicatio followed by an arbitrary number of n: applicatio, application, applicationn, libapplicatio, etc.
  3. To see how this can be dangerous, try (without root for double safety) apt-get -s remove "wine*" (-s will simulate the thing instead of doing it) — it will say is going to remove all packages that has “win” in their name and the dependant, almost the entire system…

Probably, the command that was meant is really

 sudo apt-get remove "^application.*"

(note the quotes and the dot) which will remove all packages whose name starts with application.

These commands,

sudo updatedb                  # 

are completely outside the scope of the package management. Do not remove files belonging to packages without using the package manager! It will get confused and is the wrong way to do things.

If you don’t know to which package a file belongs, try this:

dpkg -S /path/to/file

Ruby – Read/Write Modes on Files

IO Open Mode

Ruby allows the following open modes:

"r"  Read-only, starts at beginning of file  (default mode).

"r+" Read-write, starts at beginning of file.

"w"  Write-only, truncates existing file
     to zero length or creates a new file for writing.

"w+" Read-write, truncates existing file to zero length
     or creates a new file for reading and writing.

"a"  Write-only, each write call appends data at end of file.
     Creates a new file for writing if file does not exist.

"a+" Read-write, each write call appends data at end of file.
     Creates a new file for reading and writing if file does
     not exist.

The following modes must be used separately, and along with one or more of the modes seen above.

"b"  Binary file mode
     Suppresses EOL  CRLF conversion on Windows. And
     sets external encoding to ASCII-8BIT unless explicitly

"t"  Text file mode

When the open mode of original IO is read only, the mode cannot be changed to be writable. Similarly, the open mode cannot be changed from write only to readable.

When such a change is attempted the error is raised in different locations according to the platform.

A Managers Guide to NoSQL

-Article by Erik Weibust

Software design and development has undergone tremendous change over the last 30 years. Once a particular change captures the interest and imagination of the community, innovation accelerates and becomes self-propelled and change turns exponential. One such development in the last 5 years has been the development of NoSQL Database technology.

Software applications have become highly interactive with various delivery platforms and infrastructure. A modern application has to support millions of concurrent users and the data requirements have shifted from just application data to usage and analytics data. Application behavior has changed from static data capture and display, to dynamic, context-driven applications. With the above changes, relational database technology has lagged behind in innovation. Database providers have relied on 30 year old technological concepts and have applied multiple band-aids to the existing platforms to meet modern requirements.

Glossary of a few terms you need to know as you read on:

Database Schema is a well defined, strict representation of a real-world domain (such as the elements of a shopping application) within a database. All items to be stored in a database schema are expected to conform to the rules and constraints set by the schema design and no single-item can vary from the definition.

Database Replication is the process of sharing data between the primary and one or more redundant databases to improve reliability, fault-tolerance, or accessibility. Typically, data is immediately copied over to the backup location, upon write, so as to be available for recovery and/or read-only resources.

Sharding (or Horizontal partitioning) is a database design principle whereby the contents of a database table are split across physical locations, by rows instead of by columns (using referential integrity). Each partition forms part of a shard. Multiple shards together provide a complete data set, but the partitioned shards are split logically to ensure faster reads and writes.

What is NoSQL?
NoSQL is the name given to the engineering movement that birthed these next-generation databases. NoSQL stands for Not only SQL. The common misunderstanding is that it stands for No SQL, which is not true. NoSQL databases were created to solve real-world needs that existing relational databases were unable to solve. They are non-relational, distributed, schema-less and horizontally scalable with commodity hardware.

No SQL Databases are:

  1. Schema-less: Data can be inserted without being in a particular form. The format of the data can change at any time without affecting existing data. The unique identifier is the only required value for a data element.
  2. Auto-Sharding is by design an out of the box feature. All NoSQL database are built to be distributed and sharded without any further effort to the application design. They are built to support data replication, high availability and fail-over.
  3. Distributed Query support is available due to sharding.
  4. Maintaining a NoSQL cluster does not require complex software, or several layers of IT personnel and security measures. Of course, that does not mean reduced security of your data.
  5. Caching is built-in and low-latency is the expectation. Caching is transparent to application developers and the infrastructure teams.

In relation to Gartner’s Hype Cycle diagram, NoSQL is perhaps at the Slope of Enlightenment stage, with tremendous strides being made in the last 2 years towards Maturing with some of the NoSQL offerings.

Gartner's Hype Cycle

What are my Options?
There are many options to consider when choosing a NoSQL solution. They are mostly open source and schema-less. The key distinguishing factor between NoSQL databases is their design decision on how they handle data storage.

  • Key-value Storage: Membase, Redis, Riak
  • Graph Storage: Neo4j, InfoGrid, Bigdata
  • Wide-column Storage: Cassandra, Hadoop
  • Document Storage: MongoDB, CouchDB
  • Eventually Consistent Key-Value Storage: Amazon Dynamo, Voldemort
  • NewSQL: Almost relational, much simpler and easily scalable than RDBMS. Examples are voltDB, scaledb

How do I get buy-in from the team (above and below me)?
As with most organizations, new (or what is considered latest/greatest) technology is met with apprehension at best and suspicion at worst. The best and proven way to introduce something into the organization is to build prototypes of real-world scenarios, highlighting the advantages specific to your organization.

The most common place to introduce a NoSQL engine in your organization is most likely through building an application-logging prototype. With technology such as a NoSQL database, which is more of an infrastructure element, it is important to demonstrate business continuity with the new technology compared to existing technologies; thus demonstrating minimal risk to business stakeholders. It is likely that your developers may have already heard of this technology and are highly interested and motivated to use NoSQL databases. It is up to you to educate yourself on the new technology, and then educate your organization on the benefits of NoSQL based on the results of your prototype. Lastly, you can make the point that NoSQL is not an invention waiting to be implemented. Rather, it grew out of necessity for companies like Google and Amazon who built it, used it, and then open-sourced for the community at-large.

Next Steps
For more details on each NoSQL option visit We will also publish follow-up blogs posts on selected NoSQL databases in the coming weeks here at The follow-ups will be an in-depth review of the selected NoSQL databases with sample data and use cases for each.


Deleting a collection using MongoDB Ruby Driver

Suppose there is a db named ‘music’ with a collection ‘rock_bands’, deleting this collection from this db using the MongoDB ruby driver would be like this :-

client =[ ‘’ ], :database => ‘music’)

Using Mongo Shell here’s how you drop a collection :-

> use music

switched to db music

> db.rock_bands.drop()