## Sneak peak – Team Geek

When communicating with other people (not only with your colleagues), remember the golden rules which I picked up reading this fairly amazing book (a complete review will follow later) :

• Your explanations should be covered by three paragraphs at most
• You should end with a call to action

It is amazing how this simple rule is not followed in most cases of everyday non-verbal conversation.

# Surviving crisis in IT

Lately I’ve been wondering that my posts are maybe a bit too general. This is why I want to share some really existing problems with you and my attempts to solve them.

At our company we had a rough time during the last year. On worst months we had only around 500 EUR income for the whole company, however we managed to survive and here are some hints on how to achieve it.

• Transparency is the key to everything. If you are forced to delay payments to your employees, make sure they know everything about the situation. Hiding information can only lead to negative aspects, revealing it may lead to even positive reaction (for example almost all employees will just think, that you keep more money for yourself instead of paying them. Nobody will believe you, that you’re out of money too)
• By your commitment to share the status quo you call in two outcomes, which are good for both sides – people, how really rely on regular payments (for example if they have to support non-working family members or pay credit rates) will leave as soon as possible, so you will avoid conflicts with them in future (and believe me, conflicts with this kinds of people are the most terrifying) and they receive a possibility to look for a “steadier” job as soon as possible (which will mitigate their financial drawbacks).
• The second outcome will result in a win-win-situation – some people will still say “okay, I’m staying, you can pay me whenever there is more income”. For you, as a company owner this is good because of two reasons – these people commit themselves to their job, meaning they will really work (since if they don’t, there is no point in staying, they will want their money). The second reason is simple – you can rely on those people in future. Both sides will know, that there are ups and downs, and if you survived together, this will strengthen your bond.
• Next key point is the presence of a “leading idea”. And by that I understand some higher goal which your company should ideally have and try to achieve. Let’s consider an example – say, your company creates only generic websites for clients (shops and landing pages). Chances are, when in trouble, people will think – well, there is nothing special in my job, why should I even stay? Instead, if you are developing an interesting SaaS solution, which could impact thousands or millions of people, well – it’s almost everytime worth suffering for.

## Last but not least

Don’t forget to reward people for their loyalty. If you survive the crisis together and you behave like an asshole at the end of the day, the most loyal employee will be your most terrific nightmare.

## Business – fucked up style

Recently I stumbled upon such an interesting book, however it’s only available in Russian (Бизнес в стиле Ж). I would strongly recommend every project manager (not even in IT field), every business owner and other “higher” positions to read this book. It contains only 200 pages and can be read in one breath.

One can freely say this book is focused on business survival (as the title suggests) and several ideas are worth to be remembered. Author is not the last person on Russian media landscape and owns Gameland which is responsible for multiple print and online media (car tuning, computer games, cinema etc.)

Few useful tips I gathered from this book:

[readolog_blockquote ]Crisis times are similar to war times – pay no one, collect from everybody, care only for the fighters.[/readolog_blockquote]

Be ready to drastically change your business attitude (for example author, who was printing a 240 pages shiny magazine switched over to 160 pages magazine, printed on cheap newspaper paper (no pun intended)). Do not let any money leak – freeze (temporarily) all your debt flows. It’s better for each party (you and your creditor) to invest this money into further business development, because it’s the only way you can earn money and for your creditor to get his money back. Try to restructure your debts (most creditors are willing to give you discount if they will see payments from you). For the best employees (and most motivated ones) rise their motivation – if they suggest a new project, give them 100% of project’s income first year (sink it later on…).

[readolog_blockquote ]Try to be as open minded as possible – talk to people, follow latest trends. You can never know what might be the next hit during or after the next crisis.[/readolog_blockquote]

Just imagine – Russians are generally hostile towards Muslim culture, however this didn’t affect their love for hookah at all! Or sushi – Japanese culture is considered as weird, raw fish is a no-go, rice isn’t that popular… but sushi you can find on almost every corner.

Most likely, your general employee won’t care what is happening with your company – they simply care for themselves. Thus, sharing negative information with them won’t make anything better – this category of employees won’t be able to influence anything at all. However, the higher you climb on the position ladder the more information you should share. You simply can’t expect owner-like behavior if you hide important things from your top people.

I hope you enjoyed this short summary, feel free to (learn Russian and) read this book by yourself!

## The Software Development Edge – Book Review – Part III/III

Finally I gathered all the strength required to finish this review. It’s a little bit tougher than back in the school days, however I hope it might serve some educational purpose.

As explained in the last post, this review part will not continue the previous path, but summarize the whole book (in a shorter way). You can regard this as a kind “best of”.

## Core idea – Politics

[readolog_blockquote ]”Developing software is such a unique and complicated process, I can’t make an estimation how long it will take and I won’t take the responsibility for my due dates” – this is utter bullshit. Software development is just as unique as any other professional field (just ask your friends). If someone refuses to take over responsibility it’s is clearly not because he/she is such a genius.[/readolog_blockquote]

## Core idea – Crisis

[readolog_blockquote ]Act – that’s the main point. Regardless if you’re a hired crisis manager or were just moved to another project which is deep in the shit, your main goal now is acting. It will stink for a while, so don’t bother with keeping good relationships (with customers, other employees, anyone…).[/readolog_blockquote]

## Core idea – Project

[readolog_blockquote ]Keep your project within the given due date. Do it at any cost – mostly you will be cutting off unnecessary features. However you can’t fit any project in any time frames. Take your time in advance and get an honest opinion from your team members how they estimate the whole project. You really need those honest opinions and people you can trust. If you can’t, it’s time to say goodbye to those.[/readolog_blockquote]

## Core idea – Developing

[readolog_blockquote ]It might be some de facto standard right now, but still I see even in my team how things can quickly get out of control if you don’t invest time into concentrated continuous releases, called iterations. Force everyone to deliver something each week. It will require a lot endurance from you, but there is just no other way…[/readolog_blockquote]

I promised to keep it short and simple and here we go. Four core points which should awaken your interest in this book. If you want to intensify the review reading I would recommend you part I and part II, however more than that I would just suggest you go out there and buy this amazing book.

## How to write useful technical specs

I might be not that wrong in assuming that a lot of IT people out there encounter same problems regarding tech specs all the time – they become obsolete sooner than they are written. Mostly created to show the client – hey, we’re doing stuff here, here is the result, 100 pages of pure informational power. However, the result is often the same – after one glance, each team member will soon forget that this spec ever existed.

So how make specs more useful? In this article I won’t show how to formulate your spec, but more how (technically) to manage, that your spec stays up to date.

## Use LaTeX

No, not in the bedroom with your girlfriend (on the other side – who am I to judge you?), but the document markup language (according to Wikipedia).

LaTeX is not only cool – writing specs feels almost like writing code – but it allows you to maintain a healthy development process considering your spec.

### Problem No. 1

When your specs are starting to get bigger and you add stuff here and there, it is very (VERY!) hard for your team to follow up on changes. Using GIT in combination with LaTeX allows you to commit any changes just if it were code. And GIT markup fantastically highlights all changes that were made. So next time you can just give your team a link to the latest commit to they will see only the new and recent parts.

### Problem No. 2

Have you ever tried to create links within a document, say in MS Word? Yeah, you kinda able to do that, but if you add, say, a new point to your numerical list, all your links will get messed up. Regardless to say what happens if you add a whole new chapter at the beginning. LaTeX allows you to define variables, just like any programming language. Just use a simple

/label{section:intro}

where section:intro is just a clear variable meaning that your content is in the section called “intro”.

### Problem No. 3

As soon as you try to maintain your MS Word spec you realize how this program is clearly not created to write large documents. Ever tried to create a numerical list, then add a break and continue the list? Then you’ll know how easy it is to screw things up. By being completely controllable there is always an easy solution for almost everything you want to achieve with a LaTeX document.

## Use GIT

I mentioned it already in the previous paragraph, but I can’t stress it out enough – your LaTeX spec will really shine bundled with GIT. Not only you have a neat version control (and don’t need to save “project_x_tech_spec.v.1.0.docx”, “project_x_tech_spec.v.1.8.docx” and so on), an ability to link only your recent changes by sending a commit link, but you also have one place for your always up-to-date end format, because recently github learned how to display pdf-files.

So basically your pdf url stays always the same, something like this:

## Where to host code?

Trust me, even if you have just one developer you better start using version control. Github is the most common service just to do so, however if you can’t afford sharing your code with the community you got to pay for private repositories. A wide known alternative would be Gitlab, which not only allows you to host the service on your own machine, but also doesn’t charge you for creating private repositories if you continue using on-demand version. I didn’t manage it to install Gitlab on our 5$droplet (maybe I’m just not gifted… maybe it has something to do with recommended RAM size of 2 Gbyte and two unicorn worker units to be able to handle http requests – 5$ droplet got only 512 MB RAM), so we’re using private on-demand repos. However if you manage to install gitlab on your machine the following routine will be much easier, since pulling from Gitlab won’t requre any hooks as it will be on the same machine as Redmine itself.

## How to connect them?

You’ll probably don’t want maintaining two systems at a time. This is where so called hooks come in play. You can try and install https://github.com/phlegx/redmine_gitlab_hook but for me, although I set up (at least I suppose so) everything correctly, it didn’t work.  What I did instead was following:

• create an ssh-key on your server, where redmine is hosted (since chances are you won’t be able to copy the key to your clipboard you’ll need to send the file to your local machine first via scp
pbcopy < .ssh/id_rsa.pub
(I never know how to connect to my local PC, so instead I connect to remote machine and download the file)
For example - scp root@192.168.0.1:/.ssh/id_rsa.pub /directory_created_for_the_key
• now comes a tricky thought – since Redmine hooks only its local repos but your local environment is another one, we need a workaround. As depictured below you need to set up your remote origin as gitlab
git remote add origin git@gitlab.com:your_project/your_repo.git
then you push using
git push -u origin master
• To keep your Redmine repo up-to-date, you’ll need, first of all, to create one (on the Redmine server) – simply git init /home/redmine_projects/project1
• Create a cronjob – nano /etc/cron.d/sync_repos
• Repeat the line for each repository (app should be the owner of the repository. In our case it is “root”)
*/5 * * * * app cd /path/to/project.git && git fetch origin && git reset --soft refs/remotes/origin/master > /dev/null
• Wooosh! You’re done! Now every push will be visible just 5 minutes thereafter in your Redmine repo-tab.

## The mythical man-month

Would you call me arrogant for retitling this book as “Mythical technology no one cares for now”? You have the right to do so. However I want to provide some argumentation for that if it please ya.

To tell long story short – the main thesis of the title, that adding people to late projects will delay them even further is mentioned in the second chapter of the book. Until the 17th chapter you’ll deal with ancient stuff about OS/360 (what the heck is that?) and IBM 1771, Machine 881295, coding languages so ancient they make Greek Gods seem modern. I have no issues with people wanting to learn from the very basics. But generally this is not effective. If you want to dig a hole in your garden you go to the supermarket, buy a shovel and do the dirty work. You won’t, however first go and buy seeds, plant a tree, watch it grow, go to the mines, prospect the ore, process it, create the shovel blade, cut your tree (same procedure for the axe by the way?), make the handle, connect the blade with the handle and…finally dig!

Yes, you could do that, but it’s just not effective. You just rely on people who create this stuff for you. It’s important to have a basic knowledge (that a shovel blade made from paper might seem as a bad idea) but still you need other qualifications for digging a good hole.

## Is this post just about nagging or will there be something constructive?

It’s the same with this book – not only it gives the reader such outdated information (ok, ok, it was written few years ago, 1974), but it’s also written so damn complicated and jumps from one extreme to the other – it’s either written too general (although I’m not the dumbest person I wasn’t able to understand) or so heavily loaded with detailed information about things one one knows they even existed without even explaining it!

You see, this is the main point – if this book should be an introduction it clearly lacks all introductional features as explaining material. If this book is a summarization of some facts… well I guess it was good back then, but now I don’t see the point of it. The mythical man-month suggests that this book is about people, about working with people but it’s just a practice report from over 40 years now. I might seem to brag here often about the release date, but you know what – other authors show that this is clearly not an issue at all, just take a look at DeMarco & Lister (if you haven’t read my article about their book – just skip the article and go buy their “Peopleware”)

## TL;DR?

Let’s consider two quotes from the book:

Consider the linkage editor, designed to load separately-com-
piled programs and resolve their cross-references. Beyond this
basic function it also handles program overlays. It is one of the
finest overlay facilities ever built. It allows overlay structuring to
be done externally, at linkage time, without being designed into
the source code. It allows the overlay structure to be changed from
run to run without recompilation. It furnishes a rich variety of
useful options and facilities. In a sense it is the culmination of
years of development of static overlay technique.

and

The unexpectedly hard part of building a programming system is
system test. 1 have already discussed some of the reasons for both
the difficulty and its unexpectedness. From all of that, one should
be convinced of two things: system debugging will take longer
than one expects, and its difficulty justifies a thoroughly system-
atic and planned approach.

You take the meaning? First quote – my wtf moments: what is linkage editor? Cross-references? Program overlays? Overlay facilites? Structuring to be done externally? There is a lot of information in this text. But is it useful?

Second quote – a hell lot of text for saying… debugging is hard?

My advise at the end, if you really want to read this book – skip chapters 4-13 and chapter 15 and 16. Just do it, you won’t miss anything you’ll require for a start of your career. Basically in chapters 18 and 19 (of the second revision) the author summarizes his own book, commenting own statements 20 years later (revision was published in 1995).

[schema type=”book” url=”http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959/ref=sr_1_1?ie=UTF8&qid=1412691597&sr=8-1&keywords=mythical+man+month” name=”Mythical Man-Month” description=”This is the official description from Amazon, don’t come hereafter and complain – I warned you! Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.” author=”Frederick P. Brooks Jr.” publisher=”Addison-Wesley Professional” pubdate=”1995-08-12″ edition=”2nd Edition” isbn=”858-0001065793″ paperback=”yes” ]