Category Archives: methodology

Books from last quarter – part one.

I read or listen at least one book per two weeks. I want to share the list with you. First of all it is always worth to recommend good book. Second I hope you could help me. Please write your suggestion into comments. Thanks and happy reading.

This quarter list:

Crossing the charm

The must read for everyone involved in high tech industry. From the book you will learn about five stages of technology adoption, and how you need to have different attitude for marketing and selling.

 

 

Key Takeaways:

  1. “Early adopters” want a change agent. “Early majority” looks for productivity improvement for existing operations (you need to be better somehow).
  2. Elevator Speech Template – “For …. (target customers)  , who are dissatisfied with  ……..(the current market alternative). Our product is a  ………….. (new product category) unlike ………………(the product alternative). We have assembled …………..(key whole product features).
  3. segmentation, segmentation and segmentation.
    1. Enthusiast – “Name it and frame it”
    2. Visionary – “Who for and what for”
    3. Pragmatist – “Competition and differentiation”
    4. Conservatism – “Financials and future plans”

What Got You Here – Won’t Get You There

Some time ago I had a training it was great and helped me get better. The most used phrase during this training was the title of Goldsmith book – “what got you here, won’t get you there”. This book is must have! I will just put one key takeaway here, because you have to read this book to get “Twenty Habits That Hold You Back”.

 

Key Takeaways: The only person who stops YOU from the being on the top is YOU.

Flawless Consulting: A Guide to Getting Your Expertise Used

This book is must read for consultants. Want to know how to deal effectively with clients? Read the book. Author by using illustrative examples and case studies help us understand all aspects of consultant job. The book is also for non consultant, as each of us is a consultant at some point in our lives. Finally “Flawless Consulting” is less about how to consult and more about how to communicate.

Key Takeaways:

  • You have to manage the relationship – it is essential to good implementation.
  • Ideas about contract and getting commitment
  • Watch out for unrealistic expectations! (people think you should transform everything overnight)
  • You need to learn them to be able to solve their own problems after you’re gone.

Kobe Bryant. Showman

Creator of the bestseller Michael Jordan. He wrote another great biography of Kobe, who broke into the best basketball league at the age of only 17. Kobe was not only proud of himself eg. when he was asked about Jordan he answered “I’m going to be better than him”, but also extremely hardworking. He always was first at gym, and finished as last one. His live wasn’t easy but through hard work he was one of the best NBA player.

Key Takeaways:

  • Hard work is very important to your success.
  • Shows how our decisions creates our opportunities.
  • Being on the top isn’t dream, you must work even harder.

Critical Business Skills for Success

This course have five parts:

  1. strategy,
  2. operations,
  3. finance and accounting,
  4. organizational behavior
  5. marketing.

Every part is led by business professors from top business schools. In each part you will learn about everything from key terms through methodologies and case studies.

Key Takeaways: It is 60 lessons so it very hard to get key takeaways gere. This course brings MBA experience for you.

Free: the future of radical price

The book is about pricing models which give products and services to customers for free (referred to as “freemium”). The strategy works to attract users and then up-sell them at  premium level. Chris Anderson explores this idea as business strategy for today’s  companies.

 

 

Key Takeaways:

  • Sooner or later every company need to figure out how to compete with “Free”.
  • If the price is zero, we all are irrational (it is proved in other books) and take decision much easier.
  • “Generation Free”: Growing up post-Napster, younger generations find copyright irrelevant.

Designing Bots – Creating Conversational Experience

This is very important book to me, as I’m in conversational interfaces business right now. Ideal for designers, product managers and entrepreneurs – you will find out  what works and what doesn’t on real-world bot examples. Author is co creator of Slack messanger so he guide us through different bot platforms based on his experience. If you are interested in conversional interfaces use for your business, than this book is must read.

 

Key Takeaways:

  • Personality is important, but more important is to keep it consistent across the experience.
  • First things first: Define your bot’s purpose and core functionality.
  • Mainly there are two types of conversations, task-led and topic-led.
  • Use platform specific rich interactions (buttons, images, audio …)
  • When possible do not fall into bot-amnesia.

Next Quarter

Next in Queue 🙂

  • Small Data(audiobook)
  • Meaningful
  • What’s Stopping You?
  • Principles (audiobook)
  • The Entrepreneur’s Toolkit.
  • Black Swan  (Andrzej suggestion)
  • … and … feel free to make your suggestions….. in the comments

Model Driven Architecture live or dead?

In my wunderlist‘s “watch this” list I found this dinosaur movie to watch: MDA: A forlorn hope. by Uncle Bob. It was posted over two years ago and it was viewed almost 55 thousand times.

MDA is easy isn’t it? The MDA Guid has only 62 pages. We need some modeling tools and another tool for model to code transformation. Sounds easy 🙂

Few years ago, we’ve been using MDA approach in our project. We used MagicDraw for UML part and AndroMDA for UML to Java code generation (of course there are many other tools). From my point of view it was great experience. I share with my opinion below:

  • (pros) Model and Factory for free.
  • (pros) Hibernate mapping for free.
  • (pros) Documentation is up to date – you have to modify it to generate changes.
  • (pros) We focused on design, before coding.
  • (pros) All you hibernate mapping/DAO/etc is similar ( standardized – we can modify template)
  • (pros/cons) We can/have to change templates to align to ours standards.
  • (cons) Lot of  code you prefer to never read :/
  • (cons) Every time you change something, you have to regenerate code.
  • (cons) You have codebase divided into “read only” and “change here”.
  • (cons) If you forget to put additional metadata into model you’ll be doomed in future.
  • (cons) Once you change template, it is harder to upgrade tools and we have to regenerate code.

Nowadays I compare that experience to modern frameworks such as Rails or Django. I have to add comment here, what I really mean is that by using MDA approach I do not think about database mapping, DAO/repository object, I started at service level, and I have similar fillings when I’m using Rails or Django framework. I’m focusing on business logic, not how to get or save data into persistence storage.

Uncle Bob is talking about analyst as software creators, and this idea fortunately for my salary is impossible ;).

I totally agree, doing software is on much more detail level than model thinking, but … I think it wasn’t so bad to think about design on high level and then generate code and go deep in business logic details. How many times Java programers do the same job: create POJO, annotate or write XML descriptor, create DAO which looks more or less the same as another one, etc.

Let cite some smart guys from Uncle Bob post:

  • Uncle Bob: “Programmers are details managers – sorry MDA” 🙂
  • Comment: “MDA is actually based on two grand ideas:
    – raising the level of abstraction above programming language.
    – satisfying everyone with universal set of *standard* abstractions. Most of MDA failures is due to the the second idea, which is why MDA (not MDE in general) may be indeed a forlorn hope.”

I don’t want to force you to use MDA, just think about it and in …meantime … find the difference :).

Old times
Blog post before 1st May
nowadays
Blog post after 1st May

Yep, posterous is dead. Is MDA dead? Please share your opinion in comments.

 

Monitoring and metrics – Yes, of course.

I always try to convince everybody to measure. The first reaction are very different, but after a while everyone come back and says “Wow! I didn’t realize how helpful metrics can be”.

I’ve watched video: “Using Monitoring and Metrics to Learn in Development”  (by Patrick Debois from Atlassian) with pleasure. I use Atlassian tools and talk with few guys. They really care about code of their products. Patrick not only talks about metrics but also talks about technics and ideas which helps deliver better software.

Ideas from presentation:

  • smaller and frequent changes – easier to repair (dev for ops)
  • faster and better feedback – easier to find problem (ops for dev)
  • continuous integration maturity model – see slideshare presentation.
  • reuse “workflows” across environments by using virtualization – vagrant (great tool for building dev environments), puppet/chef (configuration automation and management)
  • infrastructure code repository and application code repository have to be in sync.
  • always remember that: “a lot of different monitoring levels we have” :).
  • monitoring driven development 🙂 – create a monitor check before implementing a feature (it is useless but you can think about similarities
  • monitoring tools grumble (around 00:19:20) – there is a projects by “Monitoring Sucks” (github), you can check but only one seems to be alive.
  • use monitoring as a service – this sound reasonable (pingdom, NewRelict, boundary, librato, and some others).
  • and  lot of other tools are mentioned – if you want to evaluate tools for metrics and monitoring you should watch video and note potential tools for evaluation.
  • always know the context of the metrics.
  • final thought: Metrics Driven Engineering (Etsy on the stage) – IMHO this is great idea to follow.

Whatever we will doing, it will happen our code do not work, our code stinks and become worser, but every time we figure out, we can do something with it. This is the reason it is so important to monitor our application continuously.

Patrick also mention about developer and operation responsibility sharing, he wrote a nice blog post: Just Enough Developed Infrastructure. I recommend you to read it too.