Ukrainian Tech Startups

I always return from my vacation in Ukraine with a few new books to read. There are many good book publishers nowadays, who provide a continuous stream of interesting books on Ukrainian language.

This time, among the books I’ve picked, there was one special. Not only it stood up on front of the others with an orange cover, but it also was about technological companies founded and now working in Ukraine.

Book name is “Стартап на мільйон. Як українці заробляють статки на технологіях”, which can be translated as “Startup for a million. How Ukrainians earn capital with technologies”.

Companies

It is about 14 Ukrainian companies that became successful based on technologies.

• Depositophotos
• Genesis
• Na’vi
• Grammarly
• Macpaw
• Prom.ua
• Rozetka.ua
• Jooble
• Viewdle
• Kodisoft
• Приватбанк
• Ecoisme
• Petcube
• Preply

Most of those companies are startups.

Findings

Before I started reading this book, I only knew 6 companies from this list, and had no idea that 2 of them are from Ukraine.

I decided to read the book during my flight back to Seattle. Soon I've realized that it was a right choice: such an interesting book to me that I’ve finished it by the moment I got to my destination. I always find flights a good place to read, but this time it was quite productive too. Lots of notes and highlights were left on the pages of the book and my notepad. Mostly related to 2 main topics: doing business in Ukraine and creating tech company.

Many years ago, I’ve heard that it is hard if even possible to create a successful IT business in Ukraine oriented on local market only: market is too small, local companies can’t offer competitive salary to software engineers or pay for software, and law is often too flexible to rely on it.
Companies described in the book prove this: with an exception of a couple companies, other’s have to work on external markets, which usually give a major income. Companies, like Genesis and Jooble, tried to create business oriented on local market, but that wasn’t enough for them. The only exception for this rule, is a couple of e-commerce companies: Rozetka.ua and Prom.ua (I don’t mention Приватбанк as it is a bank.)
Easy to make a conclusion that if you want to make a profitable start up oriented on Ukrainian market, it should be related to e-commerce. Not sure this conclusion is correct though.

Another finding is related to investments. Most of the companies accepted investments. Only few were financed by founders solely. Reason is obvious: not everyone had enough savings to invest into own company. Companies, who accepted external investments also received advices from investors on how to build a business.

There are 2 types of founders: serial entrepreneurs, who had already 1 or more companies behind their backs and professionals for whom that was a first company. Former benefited from existing connections, experience and capital. Later benefited from experience gained at previous work and also from investors suggestions.

Existing experience couldn’t be overestimated. Founders that had already created profitable business before, have higher chances to build a successful business.

Many companies are registered abroad (e.g. in USA) with a sister company in Ukraine, that does all the development. This helps to manage risks related to the IP and sometime unstable situation in Ukraine. HQ or development offices are mostly in Kyiv. Many founders emphasized numerous advantages of Kyiv among other capitals in Europe and world: good environment, low prices, lots of software engineers, reasonable salaries, close to EU etc.

There are always co-founders. Example with Rozetka.ua shows that wife could be a co-founder as well.

Connections are very important:

• useful to know suppliers like it was with founder of Rozetka.ua
• useful to have existing connections like it was with Grammarly
• useful to have friends who could introduce you to useful people like with Genesis
• useful to know the best around like it was with Na’vi

Each of those companies had a bad time at least once. Either there were no financing, or idea didn’t work or profits were too small etc. But all of them withstand raining days and are going to their next goal.

Lo and behold, companies with a focus on profit/success are the one that receive highest profits.

Highlights

I’ve made a lot of highlights, and want to share here only some of them:

• “Вони зазделегідь підготувалися і перед звільненням відкладали гроші, щоб прожити якийсь час без зарплати. За словами Палієнка, на момент старту Prom.ua партнери мали досить заощаджень на рік-півтора економного життя.”
• “Їсторії, коли людина стає успішною, виїхавши зі своєї культури вже дорослою, - вкрай рідкісні. Вони є, але в загальній масі статистично незначущі.”
• “Я не дуже розумію людей, які звідси їдуть. Київ - одне з найкращих місць для життя.”
• “Перші гроші Prom.ua заробив вже за кілька місяців після запуску - на рахунок компанії “впало” $5 завдяки реферальній програмі AdWords.”
• “У той час їхній проект заробляв досить скромні $500 на місяць, але навіть такі доходи давали чималий привід для оптимізму… тільки на рекламу за перший рік було витрачено $15-20 тис.”
• “Перший рік - це час дуже великої кількості експериментів, суть яких - адаптувати продукт під ринок. Головне - не впадати в зневіру й безупинно експериментувати, підганяючи продукт під ринок на базі тестувань, здорового глузду й того, що роблять конкуренти…”
• “система аналізу даних може підказати, що замовити з певною стравою, і вивести список найпопулярніших справ у цьому закладі на основі відгуків інших клієнтів.”
• “хребтом, на якому тримається тіло компанї, є стратегія.”
• “Стартапери часто забувають, заради чого все почалося. Вони відхиляються від необхідної стратегії і, впираючися у перепони, звертають у той бік, куди їм простіше рухатися. При цьому обрана спочатку мета може опинитися не попереду, а за спиною.”
• “Наступні два роки Чечоткін реінвестував до 90% прибутку в розвиток бізнесу.”

Conclusion

It is possible to create a tech startup in Ukraine. However, at this moment you might need to focus largely on external markets. You also might benefit from registering company in US or EU.

Kyiv is a great place for HQ. Cities like Kyiv, Lviv, Kharkiv and Odesa are great places for development and R&D office.

First years would be the hardest, but founders should not lose focus and work hard to achieve success.

Psychology of Everyday Things

This is the final notes after my readings the "Design of Everyday Things" by Donald Norman, which is really awesome book. Notes are kind of unstructured and, maybe, not even worth publishing here. But I'll give it a try.

Conceptual Model

Conceptual model is our way to see how the thing might work and how to operate over it. For example, when we see a bike, we can understand how it works in general be modeling it in our mind. Conceptual model is actually defined by 3 parts - affordance, constraints and mappings.
Affordance helps to understand how basically approach the thing. Constraints help to see how the best operate over the thing.

Affordance and Contraints helps to make the conceptual model obvious. For example, scissors. There are 2 holes in it. So we can understand that they are to put something inside, like fingers. While constrains help to understand what fingers we need to put inside.
Affordance and constraints helps to build visibility, which is required to understand how the thing works and what it is for. For example, scissors have clear visibility, while handwatches with multiple are not as clear. Obvious conceptual model is required for product, if you want its design to be transparent to customers.
 
Design model is how the product seen by its designer. User model is how the product seen by its user.

Design is Hard

Another post based on my notes from the book The Design of Everyday Things by Donald Norman. This one is from section explaining why design is so hard and what could be done to improve situation.

Designers pretty often can't design think correctly, because:

1. they don't know the end user of the product
2. they need to complain many rules to satisfy their direct clients, not the users of product
3. they are limitted by a business rules: make it beautiful, and not always usable
4. they know too much about the product, so can't look at it as a new user. Designers are not typical users, like programmers are not typical users of their programs.
5. not always designer is responsible for desing, it could be done by other non-professional, like programmer.
6. there is always a set of "special people", who have differences, like left-handed, deaf or blind users etc.

One of the issues of many modern products is their creaping featurism. Creators tries to put too much of features into the product. Each feature brings more complexity than it should. Because it usually comes with another control, another window, a couple of use cases and a some options. Instead, the product should come with minimal viable set of features.
Funny, but there is also a list of rules how to make things wrong:

• make things invisible: increase gulf of execution and establish gulf of evaluation, so user won't know what is happening and where they are
• be arbitrary: use non-obvious commands and names
• be inconsistent: change the rules, user different rules in different modes, have multiple different modes
• make operations unintelligible: use unknown abbreviations, unclear messages and errors.
• be impolite: insult users
• make operations dangerous: allow a single erroneous action to destroy invaluable work, make it easy for distatrous things to happen.

In opossite to all this "bad" rules, the system or product should invite user to explore it, play with it, learn it without a need to study huge boring manuals. System should be safe for user to use, it should give user hints, suggestions and advices so user can explore it even more. Visibility and mapping should plan an important role.
Design should:

• make it easy to determine what actions are available and possible at any moment of time
• make things visible
• make it easy to evaluate the current state of the system
• follow natural mappings between intentions and actions, between actions and results, between that available information about the system and actual system state.

Seven principles for transforming difficult tasks into simple:

1. use both knowledge in the head and in the world: this is where manuals could help, however one should not rely on the fact that user would study manual before he/she starts working with product, usually user get to the manual when has issues.
2. simplify the structure of tasks
3. make things visible
4. get the mappings right
5. exploit the power of constraints, both natural and artificial
6. design for error
7. standardize

Err is human...

This is my second post based on notes from the book The Design of Everyday Things by Donald Norman. As I mentioned in last post, I loved the chapter about human errors and mistakes and how to design things to avoid this mistakes. So, here are my notes...

There are different types of errors:

1. data-driven errors
2. capture errors
3. description errors
4. associative activate errors
5. lost-of-activate error (forgot what wanted to do)
6. mode errors (forgot in which mode)

It's not always easy to detect errors because:

1. feedback is not always available (lack of visibility)
2. different level of seeing error (you're looking error at more low-level while it's a level or a few above)

Human Memory

I've read an awesome book recently - The Design of Everyday Things by Donald Norman. I must say that didn't expect much of this book. My thought was "just another book for designers on how to create usable things". There was however something pushing me to read this book, maybe because  I've read about it in the In the Plex; book was references as the one that influenced Google's founders. Well, now I can understand why. Even thought the book is mostly about trivial things that everyone should understand and know. In fact, it's not true. Not everyone understand and know. I didn't. So many openings about regular things, views from different perspectives, inspirational rules etc.

There are many topics that I liked in this book. But the chapter named "To Err is Human" maybe the most favorite for me. Not only because I make so many mistakes and errors all over the time by myself, and it's nice to understand how this works (and how I work). But because author gives very good explanation on how human memory and brains work.

I made some notes during reading this book, and decided to share some of the them that are related to how human memory works. I also was thinking how this apply to the AI. And made some interesting openings for myself too.

So here are my notes...

MOBI version of The Architecture of Open Source Applications book

The Architecture of Open Source Applications is a great book where one can find the description of the architecture of the 25 open source applications, like Eclipse, LLVM, Mercurial, HDFS and Berkley DB. This book is free to read in the HTML format online, but if you want to get a PDF or Kindle version, you'll need to buy it either at Lulu.com or at Amazon.com.

Of course the recommended way is to buy the book, as all royalties from these sales will be donated to Amnesty International. But you can download a MOBI version for Kindle of this book for free, just continue reading.

First, want to tell a short story. After I found a free SICP version for Kindle compiled from HTML files at github.com/twcamper/sicp-kindle, I was looking for a chance to create something like that myself. And then I found the AOSA book. It has an HTML version, and I wanted to have a MOBI version to read it in my Kindle.

And so I made a Kindle version of The Architecture of Open Source Applications book and currently it's available from github.com/rkhmelyuk/aosa-mobi.

Download a Kindle version of the AOSA

Book Review: 97 Things Every Software Architect Should Know

More then year ago I bought book 97 Things Every Software Architect Should Know for myself. I was expecting to get a book with some useful technical advices how to create cool software architecture,- that's what was always interesting for me.

Instead I've got the book with 97 small articles, each 2 pages long. No technical advices, no silver bullet, no advices on what and how use design patterns or modern technologies. Truly say, after reading few articles, I was upset. And leaved the book on my bookshelf and move on.

A year later, ie a month ago, I've took this book into my hands and decided that it's time to try to read it again. (Yes, I have a habit to re-read books again a year or two later, as found that it helps to understand much more and see the forest behind the trees).

I'm still reading this - few articles per week,- but decided to note my thoughts as review in this article.

In this attempt, book is very interesting. A year later my vision was changed cardinally again and now, I think, I can understand what those guys mean when they were writing their posts. These all can be said simply in one sentence:
Software Architects are bridges between business needs, software needs, technical needs and team needs.

Especially interesting were next articles for me (remember, I'm still reading):

• Don't Put Your Resume Ahead of the Requirements


• It Is All About The Data


• Pattern Pathology


• If You Design It, You Should Be Able to Code It


• Empower Developers


• Chances Are, You Biggest Problem Isn't Technical


• Business Drives


• Great Content Creates Great Systems


• Start with a Walking Skeleton


• Communication Is King; Clarity and Leadership, Its Humble Servants

I'm sure articles' titles are saying enough, so will not describe them. Want know more - just go and buy (as I did :)

A week ago I was reading "Business Drives" article. And especially remembered the summary of this article: "The long-term interests of the software development team are best served when business drives". And I agree with this summary. It's sad to know, that many software developers are still in the race for better skills and modern technologies if this is in damage for the project and business.

It's one of that books, that reminds that software is making by humans for humans.

So, my advise is to get and read this book; hope you're ready for it and hope I'm too :)

PS: Just found another review of this book http://dotnet.dzone.com/news/97-things-every-software

Beautiful Code

Зовсім недавно повернувся зі Львова. Купив собі в Гіаді декілька цікавих книжок. Серед них і Beautiful Code. Тільки от почав її читати. В книзі міститься 33 історії від відомих програмістів, в яких вони діляться враженням від певного коду чи технології. Кожна історія проникнена поглядами і думками на цікаві речі, що розглядаються з призми красивого коду. Інколи код не зовсім-то й красивий на перший погляд, і автори намагаються відкрити ту красу, що побачили вони. А ще автори не відчувають жодних рамок у виборі красивого коду, і в книзі можна зустріти C, C++, Perl, Java, Python. Так що раджу почитати.

Задумався я над UML. Вчу студентів, що це дуже корисна річ, часто використовується в реальному світі. Допомогає не тільки спроектувати програму, але і донести свою думку до інших, зрозуміти чужу програму; є важливою частина документації.

І справді, UML буває корисним для того, щоб спроектувати програму, якщо це взагалі можливо зробити в повній мірі. Донести думку до інших за допомогою UML - річ також нетривіальна, хоча все залежить. Щодо технічної документації, то я прихильник думки, що найкраща документація - це сам код програми (доречі тут можна почитати про це більше).

А ще часто доводиться чути думки, що UML - це зайве, що все в голові можна спроектувати, і при цьому особливо "ясно видно динаміку". Інші не розуміють, навіщо ці квадратики та кружочки; a це й чоловічок (которий актор, чи то пак актант) взагалі смішно виглядає. Інші і не знають про це або знають, але не пробували.

Кожному своє. Я ж використовую UML, точніше ту частину, що мені справді допомагає. Я не пробую спроектувати всю систему, бо зазвичай це є неможливо через складність, величину системи чи плинність вимог. І звичайно я не завжди використовую UML, тільки коли це потрібно.

Натомість при розробці певної функції програми, що виходить поза межі стандартних шаблонів та правил проекту не можу обійтися без діаграм випадків використання, класів та послідовностей. Цих трьох діаграм для мене достатньо.

Спершу визначити список випадків використання та їх сценарії, як результат визначити список додаткових питань та білих плям в специфікації. Після цього вже на основі прецендентів паралельно будуються діаграми класів та послідовностей. Роблю це все на листочку або на боарді. Зазвичай, починаю з основного і закінчую другорядними класами та зв'язками. Найцікавіше потім переробити систему, починаючи з найпростіших другорядних класів та закінчуючи основними. Наступне просіювання починається при написанні коду. Знову ж таки, писати починаю з найпростіших і/або другорядних класів. Це не тільки дає час подумати над удосконаленням основних класів та інтерфейсів, а також прощупати це все ручками в коді, визначити білі плями, розбіжності та несходження.

Ось так вона, думка, спочатку матеріалізується на бумазі, відточується, потім перетворюється в код, і ще раз відточується.

І взагалі, дуже цікаву книжку Крега Лармана Применение UML 2.0 и шаблонов проектирования. Якщо є перша версія, то можна почитати її, як це колись зробив я. Раджу всім, особливо студентам, що хочуть зрозуміти принципи проектування та розробки ОО програмного забезпечення.

Google Books

English version by Google Translate

Не секрет, що у світі Google Books відбуваються чималі зміни.
Про це все розказує сам Google.

Сервіс дуже цікавий, і сподіваюся кількість повністю доступних та щойно виданих книхо з часом збільшиться. Адже є книжки, яких вже і не купиш, а є книжки - як хочеться купити або навіть потрібно купити, але змушений часто це робити без перегляду хоч якогось контенту. Гугл може дати можливість віртуального швидкого перегляду книжки перед купівлею, - наче ви в справжньому магазині.

Подобається також можливість створювати власну бібліотеку. Або вставляти фрейв сторінку із книжкою :)

"Implementation Patterns" by Kent Beck

В дорозі до Львову і назад я все-таки знайшов час, щоб дочитати до кінця книгу Кента Бека (Kent Beck) "Implementation Patterns". Дана книжка є таким собі збірником паттернів по написанню коду. В дечому вона перехрещується із всім відомою книгою "Code Complete". Книга орієнтована на Java програмістів; приклади в книзі приводяться на Java, розглядається навіть Collection API, виникає навіть деколи відчуття, що декотрі шаблони підточені під Java.

Взагалі, книжка має досить просту і зручну структуру. Ця стуктура позволяє вам перечитати книжку від корочки до корочки, а також користуватися як каталогом шаблонів.

В ній можна знайти такі розділи:

1. Theory of Programming розказує про основні цінності та принципи створюваних програм. Виділяється 3 цінності ПЗ, що слід досягати – це взаємодія, простота та розширюваність.


2. Class - біля 17 шаблонів (типів) класів, що зустрічатимуться програмісту при розробці програм. Цей розділ описує, які класи можуть бути, як слід виділяти та створювати класи та інтерфейси.


3. State. Такі шаблони, як Direct Access, Indirect Access, Variable, Field, Var Args, Parameter та ще коло 20 патернів. Ці шаблони описують стан (дані) класу, як правильно організовувати стан, як правильно оформлювати доступ, ініціалізацію тощо.


4. Behavior. Ще 14 шаблонів повязаних із поведінкою. У доповненні до опису шаблонів пов'язаних із станом класів, подаються також шаблони поведінки, роботи із даними. Розглядаються потоки виконання програм і шаблони повідомлень, якими обмінюються класи.


5. Methods. Ну і як без методів. Цій частині виділяється окремий розділ, який описує такі шаблони, як Factory Method, Helper Method, Query Method, Method Object, Creation, Composed Method etc. Я в свою чергу звернув увагу, на Method Object: перечитуючи його, я згадував усі ті рази коли він міг мені знадобитися.


6. Collections. Автор звертає нашу увагу на бібліотеку колекцій, що існує в Java SE. Доречі, мене зацікавили графіки-порівняння залежності часу виконання операцій від кількості елементів для різних реалізацій контейнерів.


7. Evolving Frameworks. Окремий розділ, присвячений фреймоворкам.

Книжка має всього 176 сторінок та опис понад 100 різних шаблонів. В цілому, книга дуже цікава! Підхід автора до постановки проблеми та висвітлення рішення мені особисто сподобався. Не буду казати, що ця книга must read, але якщо прочитаєте, то і самі все зрозумієте ;).