DEV Community: Alex Iskold 🗽

Anyone have experience in organizing a Hackathon in NYC ?

Alex Iskold 🗽 — Wed, 30 May 2018 11:43:43 +0000

Hey Devs, I am looking to help one of the Techstars NYC companies help organize a hackathon. Anyone has experience in organizing and is willing to connect with the company for quick 5-10 min feedback? Thank you!

New pure functional programming language - ETA

Alex Iskold 🗽 — Mon, 28 May 2018 13:16:07 +0000

Last summer we had a pleasure of working with Jyothna and Raul - creators of ETA - a new functional programming language. ETA is interesting because it is based on Haskell and runs on top of JVM.

This implementation combines purity of functional programming that's Haskell with portability and enterprise readiness of JVM. Do you use functional programming at work or in our personal projects? If you do check out ETA and let me know what you think about it.

What is the API for YOUR startup?

Alex Iskold 🗽 — Sat, 26 May 2018 23:20:01 +0000

I was recently chatting with one of the Techstars founders and found myself asking her, "What is the API for your business?"

This may sound like an odd question, but it actually is not.

Every single startup, and every single business has an interface that it offers to the world. Some of these interfaces are super simple, like Google—all you can do is search; some are more sophisticated like ordering things from Amazon—you can browse, search, add to cart, order, request a refund, etc.

Even if you aren't an engineer or a product manager, it is really useful to think about the API that your business will offer to the world. Thinking about your business as an API allows you to gain a great deal of clarity about what your business actually does and why.

API mentality forces you to be minimalistic and clear.

What is an API?

API stands for Application Programming Interface. You can think of an API as an interface or a contract through which a software component, a web service, or in our case, a business, interacts with the world.

To put it differently, an API is a protocol for communicating, sending requests, and receiving responses from a software component, a web service, or a business.

For example, take a simple check box, a UI component that we see around the web. The interface for a check box allows you to check or uncheck it.

/check -- causes checkbox to be checked 
/uncheck -- causes checkbox to be unchecked

A different example of an API would be, for example, launching 10 servers on Digital Ocean's web service cloud. That API may look like this:

/launchServers?numServers=10 -- starts running servers in the cloud.

In this last example, the launchServers command allows the user of the command to specify the number of servers to launch. Most services allow this kind of customization or parametrization for maximum flexibility and reusability. It wouldn't make sense to have a different command to launch 10 or 20 servers, since it is essentially the same command.

What is the Business API?

When thinking about your business API, it is handy to think about the key concepts of your business, and commands associated with them. What can the users of your business do? Here are some simplified examples of the Business APIs that you will likely recognize:

google.com/search?term=techstars

amazon.com/browse?category=books
amazon.com/buy?bookId=b&customerId=c

uber.com/orderCar?location=loc&customerId=c

twitter.com/postTweet?text=t&userId=u

facebook.com/friend?userId=u&friendId=f

Modern businesses run in the cloud, and the way we interface with them is by using HTTP protocol. This may be counterintuitive because most of us, as end users, see pretty screens and friendly apps, but the nuts and bolts interface, the actual commands, are sent over HTTP.

The reason this is important is because HTTP reminds us of the actual bare bone APIs of these businesses. These are raw, direct interfaces that ultimately define EVERYTHING we can do with these services.

How to design your Business API

Now let's focus on YOUR business. When you are starting out, you are doing a whole bunch of things—understanding your founder market fit, talking to customers, thinking about your unique insights and advantages, your go-to-market strategy, and a ton of other things.

Building the API for your business should be one of the early activities you do.

Use HTTP protocol (it is not that hard!) and map it out. Way before you build your MVP, design your API.

The exercise of designing your API will help you gain clarity about your business. You will make decisions about what you will or won't do in your MVP. You will prioritize some commands over others. You will realize, by writing on a piece of paper, whether you are doing too much or not enough.

Make your API as simple and as elegant as possible. Don't think about what to add, think about what to remove.

Your basic API will be an amazing tool for helping you communicate with your customers and with your team. It will also be a stepping stone to building your MVP.

Once you design your API, and are happy with it, implement it. One by one, get the raw API working via HTTP. That's right, you don't need fancy UX and pretty apps to start, you can get a feel for your business by implementing your API.

Evolving your API with your business

As your business evolves and grows, so will your API. Keep updating it and making it better. Keep adding to it, but be stingy. The best companies have simple APIs.

Think about Google; it has an amazingly simple interface, but it does something incredibly complex inside. Similarly, Steve Jobs always pushed Apple to make the interface as simple as possible, something that just works. Apple products hide incredible complexity and engineering ingenuity beneath a simple interface.

You want your business to be as simple as possible, and the services behind the interface as valuable as possible.

As your business grows, different parts of your business will evolve their own APIs. You will have a public interface, and internal interfaces. It is incredibly helpful to keep all your interfaces simple and clear. Push yourself to always have clean interfaces and use them.

Your own business should always be the first and biggest customer of your own API.

As your business grows, so will the ways it can be accessed.

You will have a desktop and mobile site, text messages, bots, iOS and Android apps, and dozens of other ways your business can be accessed online. All these things can be thought of as clients of your API, clients of your business.

We now live in the world of cloud services and automation. Every major web company, whether it is Google, Amazon, or Facebook, has APIs for the services they offer.

In the future, every single business will be accessed not just through a graphical user interface, but programmatically. As AI and automation enter our world, more and more transactions and access will happen through web services and APIs.

As a startup you can prepare yourself for that exciting future by simply starting to think about and writing down YOUR API.

What commands does YOUR business offer to its customers? What is YOUR API?

Your MVP is minimal, but is it viable?

Alex Iskold 🗽 — Sun, 20 May 2018 19:34:52 +0000

In this day and age, when startups talk about MVP the emphasis is always on minimum.

Everyone encourages founders to not wait too long to launch, to get it out there, to get feedback, and to start learning from the market.

That is great advice in general, and I am personally a big fan of going fast vs going slow. Yet, to me there is a subtlety that is lost in the message, which leads to misinterpretation and bad outcomes.

The minimum product that comes out still needs to be viable.

If a product is too simple, and falls below the bar, it won't be well received, and won't be likely to take off. If the product is too simple, doesn't solve the problem, and doesn't activate and retain the customers, it is not an MVP. It may be a prototype, and there lies the difference.

MVP is good enough, and can be improved to be great one day. Prototype isn't good enough.

Simple, but not simpler than it needs to be

Einstein said that everything should be made as simple as possible, but not simpler. He implied that difficult problems are just that - difficult, and ultimately, some things can't be simplified.

A great MVP isn't only simple, it is also sufficient.

It embodies the solution to the problem, or an elegant approximation to a solution that is good enough. Sure, it lacks features. Sure, it is raw and unpolished, but good MVP can be recognized as having the potential to be great – to fully solve the problem.

Viable literally means alive

If you look up the word viability in the dictionary you will see that it comes from the Latin word vita, meaning life.

Being viable literally means being alive.

How can a product be alive?

Products that we fall in love with have a vital quality to them. They feel great, respond right – they delight us with their UX, simplicity, and the way they solve the problem.

They feel different, they feel alive.

A branch of science called Complexity studies patterns across disciplines, and seeks to understand the dynamic of different systems.

Roughly speaking, Complexity distinguishes between systems that are in the state of chaos, dead and alive. Systems that are considered alive are close to the edge of chaos. They have enough interesting dynamic built in, but they aren't out of control.

The analog for MVP is that you can have a product that has too many features – it's chaotic and hard to understand. On the other extreme, you can have a product that just doesn't have enough built in. It is not good enough, it is not alive.

It is in the middle that you find your great MVP. It is minimal and vital. And key to vitality are feedback loops.

How to think about your MVP

It turns out that the key to vitality is feedback loops. This is what makes natural systems alive and this is what makes great software alive as well.

Strive to create a minimal product that has correct feedback loops.

Step 0: Talk to customers and confirm verbally that you are on to something. Do the unscalable things to validate the market.

Step 1: Map out MVP based on your gut and understanding of the market.

Repeat steps 2-4 until done:

Step 2: Remove features that feel unnecessary.

Step 3: Combine features that can be combined, simplify.

Step 4: Check the flows and feedback loops. Are you solving the problem you set to solve? Is the system dynamic enough? Will it be alive?

What you are doing is you are focusing on a minimal set of features, but not at the expense of viability. Sometimes after removing a bunch of things you may need to add some things back.

Viability for different types of businesses

How exactly to make your MVP viable is as much art as it is science. But there is science to it, for sure. Let's take a look at different types of businesses to get the idea of what to look for.

Consumer utility/social: For consumer product activation and retention are two important feedback loops. The product is not immediately viable if users aren't activated. Similarly, the product won't be viable in the future if the users aren't retained.

Activation for most consumer products is one or more actions that the user has to perform to become engaged and have potential to be retained. For example, on Twitter, an activated user may be expected to follow at least 10 other users and post a Tweet. To become retained, the user is expected to come back at least once a month and read a tweet.

Marketplaces: For marketplace the key thing is to enable liquidity. For example, for Airbnb, it wouldn't be enough to just list the apartments or express a need for a rental. Both need to be in place. There needs to be a mechanism to match buyers and sellers. Most often it is done via Search and Discovery, but in different types of marketplaces matching can be done differently.

Again there needs to be the basic feedback loop around activation, and ultimately each successful seller and buyer need to experience the joy of the first transaction. What happens next is equally important for viability. Could Airbnb work if you removed seller and buyer ratings? Perhaps not. Maybe this feedback loop is critical to make sure that the marketplace can self-organize and weed out bad players. Including or not including ratings into the MVP is a critical decision.

E-commerce: For e-commerce business, the ability to find and buy products is critical. Purchase is the feedback loop. But a bunch of other things need to work correctly. For example, imagine an e-commerce site without the search capability. It might be fine if you have a handful of products, but not if you have a large catalog. Should search be part of your MVP?

For retention, you need to decide what will make the users come back. Is it promotions? Is it personalization? Perhaps subscription? Maybe a mix of all of it? What is the minimum investment you make in MVP that maximizes the chance of users sticking with you and coming back for more?

SaaS: For SaaS business, activation is signup and retention is non-churn. The first one relies on building features that are needed, and the second relies on repeat usage. The second feedback loop is a lot harder to get right in MVP, but it's pretty important.

Unlike consumer businesses that don't charge, SaaS products are paid. The fact that you are paying for something is already an incentive to use it, but it is not a guarantee.

For more details on building your MVP go read this awesome guide. Below is the image from the post.

Compute your MVP

There is a method to great MVP. It captures and brings to life the minimum, yet sufficient version of your solution to a business problem.

Don't rely on luck or minimalism to get you to YOUR MVP. Compute it.

MVP is a product computation on a napkin or a whiteboard. MVP is not about furiously typing code. Rather, a great MVP is about rigorously thinking.

We can't predict the future, but we can do better than roll the dice.

We can be intelligent about our MVPs, make them simple, build in feedback loops, and make sure they have a shot at being alive.

Please share your MVP experiences here. What worked / didn't work for you in your business?

5 Tips for Startup Engineering Teams

Alex Iskold 🗽 — Sun, 20 May 2018 16:38:15 +0000

Every single company depends on software, and startups are no exception. Software has gone from being critical to every business, to BEING the business.

Software creation is an art, a craft, and a process.

Building and shipping software is a marathon that lasts the entire lifetime of the company.

To ship software effectively you need to establish cadence, and a process. In this post we discuss a lightweight framework and tips that startups can follow to ship quality software regularly and effectively.

1. Setup sprints

To start, you need a light process for identifying what to build and how to actually build it. Teams that choose to ship without a process end up being chaotic, stressed out, and ultimately not successful.

Here is a light process, called sprint, that will help your team ship to production every 2 weeks.

The sprint starts with planning what to build. The features are organized into two lists – all features you want to implement, and a subset of features you will actually implement in this upcoming sprint.

Before the beginning of the sprint, the team gets together and re-prioritizes all features. Once the ranking is complete, the top 3-5 features are moved into the list to be completed for the upcoming sprint.

Once the features are selected they are LOCKED for this sprint. You can’t add new features in the middle of the sprint.

This is critical. Making changes in the middle of the sprint throws off the timeline, and causes massive stress to your engineering team. Avoid doing this at all costs.

Similarly to having 2 lists for features, you will have 2 lists for bugs as well. Before the start of each sprint, re-prioritize all the bugs, and move the ones that need to be fixed into the list for this sprint.

Here is a sample setup for your sprint:

Planning: 3 days before the start
Fix Bugs: Day 1: Wednesday
Fix Bugs: Day 2: Thursday
Code: Day 3-7: Friday – Thursday, except weekends 🙂
Test: Day 8: Friday
Test: Day 9: Monday
Ship: Day 10: Tuesday
There are a few tricks to setting up the sprint.

Never release into production on Friday, or in the evening.

Why? Because things tend to break and then you might end up ruining your weekend or be stuck in the office all night.

The second trick is always fix the bugs first before coding new features. This way you are making sure that you are building new features on a solid foundation.

If your sprint is 2 weeks, you have 5 days to code new features. This is plenty of time assuming you broke down your features into small chunks. In fact, this system forces you to do that. You are always making progress, improving the product, and moving forward.

The last part of the sprint is testing and making sure you release quality software.

The last few days of each sprint should feel like a spiral.

You test, find bugs, and fix them. The closer you are to the release the fewer bugs you should find. Once there are no bugs found, you are ready to ship.

When you are in the home stretch of the release, it pays for everyone to focus on specific bugs or features together. When everyone is focused together you squash down a bug faster and then move on to the next problem. This strategy helps the entire team spiral down toward the release together.

2. Prioritize and handle emergencies

In addition to implementing sprints, get your team to always prioritize and stack rank features and bugs.

When everything is important, nothing gets done.

Create simple and clear language that everyone can adapt when talking about priorities. For example:

P1 – highest priority, business critical
P2 – important, needs to get done, but not critical
P3 – not important, nice to have

If there is a P1 bug that is found in production, and it impacts the business, you need to pause the release, and push a fix into production. This situation should be rare.

If you finding that this happens all the time, then you aren’t doing a good job testing and fixing bugs in the final stages of your sprints. You need to revisit how you are handling your spiraling down toward the release.

As you review your lists of features and bugs, you re-rank and re-assign priorities. It is totally fine to have priorities change between sprints, just not during the sprint.

3. Pair program and test

Agile software development comes with a toolbox of methods to help build high-quality software. My favorite two are pair programming and testing.

Pair programming is literally two engineers working together. One is typing the code and the second one is watching.

Pair programming may seem like a waste of time but it is actually a more effective way to code, especially critical pieces of your system.

Pair programming increases the quality of the code and establishes awesome camaraderie between team members. You create clear and bug-free code out of the gate.

Testing, and unit testing in particular, is another strategy to ensure quality code. It is actually pretty hard to write and maintain a body of tests for your code, but it is necessary and it pays off. After all, if you didn’t test something how would you know it really works?

There are two types of tests that are particularly helpful. The first set of tests is for critical pieces of your software; things that just can’t break. The second is a set of tests that exposes the bugs you find. Whenever you find a bug, first write a test that exposes it and then fix the code. This way you are certain that if the bug returns your test will catch it.

4. Refactor your code

Like anything else in the universe, software decays over time. This may not be as obvious because we don’t readily see rust in the code, but it surely is there. Over time, large-scale software becomes tangled and fragile, and needs to be refactored.

The way to deal with this is to constantly refactor, or improve your software. Much like you go to the dentist for regular cleanings, you need to proactively clean your code.

Encourage engineers to remove unnecessary code, and constantly improve the software to make it better.

In addition, every 6-8 weeks schedule a cleaning and improvement sprint. In this sprint instead of business features, the team is focusing on cleaning up the code, making it better, and writing tests.

5. Create a happy and productive engineering team

It is really easy to grind down your engineering team, and most startups manage to do it quickly.

Startups thrive on chaos, but a chaotic approach to building software just doesn’t work. It is like trying to sprint through a marathon – you can’t do it.

Writing software is a highly creative and intellectually intense activity and requires a fresh brain, clarity, and a specific cadence. Software engineering can be either incredibly rewarding or incredibly stressful.

Setting up sprints and having clear priorities is a great first step to creating a happy and productive engineering team.

By creating cadence you reduce stress. By enabling your team to ship to production frequently, you are making the engineers happy. After all, there is nothing more rewarding than seeing the code you created work and make a real difference in the world.

Please share with us the strategies and techniques you use for building software in your startup.