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) :

  • Ensure that your email can be read in 10 seconds.
  • 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.

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 ]Be ready to denounce your previous experience, even if it was good and successful. Especially during crisis times.[/readolog_blockquote]

[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 ]Always pay your debts (like Lannisters) – even if it takes you years.[/readolog_blockquote]

[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.

[readolog_blockquote ]All your employees are divided into three categories: Predators, Parasites, Owners and Sheep.[/readolog_blockquote]

While almost all your ordinary employees can surely be tossed into the sheep category, proceed with caution when creating a profile for your top management. You should avoid having predators and parasites at any cost and should encourage owners or owner-like behavior. Predator’s real goal is to snatch. For his own profit he will without a wink put your company in danger. Parasite is all about creating a busy impression – his input is extremely low compared to salary, and all his energy goes only into persuading you, that he is busy doing stuff. Owners are the most rare category of top personal – they treat your business like their own and are really willing to do everything to make it prosper. While during peaceful times predators and parasites will most likely successful hide their nature, giving themselves as owners, crisis time reveals such characters very quickly. Non-loyal employees have no right to be in your company. Your best guess would be if a top manager declines your offer to decrease his salary during crisis time in exchange for a higher share in company’s revenue – it simply shows that they don’t believe in your success and your clearly don’t need such people.

[readolog_blockquote ]Share more information with your key employees.[/readolog_blockquote]

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.

The Software Development Edge – Book Review – Part II/IV

Let’s continue where we left last time.

Modelling

It is important that you are able to explain your software to non-coders. This however involves other techniques than showing code (when abstracting a bit, showing code might be the worst way to explain software).

The other extrema – typically found in “management level” PowerPoint presentations, showing absolutely nothing useful at all. Avoid it.

Writing code

As a it project manager you should be familiar with the language your team is using. Even if you come from a different language and were a professional coder yourself, it doesn’t always mean that you will know which problems the team using that specific language will encounter.

Since beginning by reading books is quite terrible and boring idea the best way to learn a new language is to write a program that covers a lot of topics (and in turn, this topics could lead to serious problems). You need a standard program.

Standard problem

It should cover:

  • (Console) line in / output
  • Retrieve data entered by user
  • Simple algorithms
  • Long term data storage
  • Standard data structure like linked lists
  • How to deal with exceptions
  • How will the program scale, will it adapt to new requirements

A wonderful solution is provided by the animal game (I’ll cover that on an extra page).

Get out!

Each product has only one goal – to suffice the customer’s demand.

Even the smallest projects tend to grow and expand. If you omit integration process the entropy will finally win.

Convince your superiors to provide you with best people possible for the integration process. Every project needs its “king of deployment”.

Continuous integration and version control are your tools to go – someone messed something up? Just revert his/her commit. You need a build every night with all tests up and running? CI is your friend.

Avoid “we’ll write a script for this problem” at any cost. Scrips are fragile and are hard to debug. Your road to hell is paved by scripts that got out of control.

While integrating there are only few ways to do things right and a lot more to mess stuff up. Take the integration seriously, invest every possible minute in it.

Compromises

The two most important thing you’re obliged to do as project manager – keep your project within initial borders and don’t let it die a slow feature-death.

I think everyone knows the basic triangle – volume, resources, time (pick two). Marasco however adds a fourth dimension – quality (nobody will care a year later on if you delayed your project or exceeded budged, only quality will remain).

At this point a small digression – Marasco now translates this thoughts into some mathematical formulas. Although I’m not a fan of stuff like “If we assume normal distribution we can calculate the probability of our project to fail…” – please don’t do that. If you ask every team member “can we do that project?” – their answers is your best probable guess, not some distribution. However some conclusions are to be considered:

Like Brooks said – most project fail because of lack of time compared to all remaining reasons combined(!).

You can’t compensate lack of one parameter by the other (in big volumes).

You should adjust parameters equally (you can’t add a ton of quality with just one week development time)

Time estimation

As a project manager it is your duty to create an atmosphere of confidence – nobody should be punished for not being able to give a perfect time estimation. This only leads to defensive mechanisms and developers will often increase the estimation to be on the safe side which in turn is bad, because you can’t rely on this numbers.

What is the main source of all evil project problems? Basically every project manager sees the working time estimation (for the whole project) as a working document, while their superiors see the time plan as a contract. Often it arises two types of time plans – one for the outside world and one for the inner development. This is a little fraud and Marasco recommends using one honest time plan.

What are main reasons for bad planning? First of all – there are almost never known all connections between certain software parts. Just use some simple combinatorics – if there are two parts that needed to be connected, there are only 2! = 2 ways of doing that. If there are three parts we have 3! = 6 ways of combining them. Let me just tell you, that n! increases really fast… You can prevent that by using small iterations, because by forcing to release a working product at the end of an iteration you can reveal hidden dependancies.

Second main reason is that delay may sneak in unnoticed. Brooks said – a delay by a year starts with a delay by one day.

If time estimation was given honestly your usual project delay should be around square root of remaining time. Let’s say you are at time point 0 and your project is estimated by 16 weeks. This means that you will probably finish between 16 and 20 weeks from now on. If you are in week 12, meaning that 4 weeks are remaining (and everything went fine so far), project delay should be around 2 weeks, meaning total development time between 16 and 18 weeks.

If you end up being faster than square root of a given estimate – you have a typical example (and problem) of someone being too defensive. The only right thing to do is to fire those people.

So basically you have following: ideal time estimation = ITE = good.
ITE +1*sqrt(remaining time) = help required.
ITE – 1*sqrt(remaining time) = excellent.
ITE +/- 2*sqrt(remaining time) = both cases very bad

How to achieve honest and objective estimation? Note every estimation (good thing is, nowadays every task tracking software supports such features) then write down each result based on given estimation. This will help you calibrating your project and the work of each individual project member.

Remember – not the result is important but rather its predictability.

Project rhythm

Just like a lot of stuff in our lives, even software projects follow certain rhythm. Compare it to a learning curve – at the beginning development process is slow – you are planning a lot of things, organize them and do research. Then you gain speed – the main process begins. When reaching the end state you might encounter speed decrease because a lot of little problems pile up and now is the time to solve them.

I bet you can confirm it on an intuitive level – projects start heavily, then accelerate and then stick in sort of swamp. Sometimes a feeling arise that you cross the finish line barely walking.

If we translate this into iterations we can encounter that there is negative “force” at transition points. This is where you as a PM should invest your energy to get the project curve up again.

Some interesting derivative information from that research – about 60% of required knowledge you receive during the first 40% of the project, but at that point only about 25% is effectively done. It lowers the risks (because you are investing time in planing and research), but on the downside you can’t show a real progress. To discuss the importance of the “learning” with your superiors you should prepare for example a list of risks and how the learning might reduce or even completely remove such risks.

Right now, as I’m finishing the second part I realize that it just takes too long to write such a detailed summarization and, what bothers me even more is that it makes it even harder for my rare visitor to follow such an analysis. Therefore I will switch from now on to shorter, more personal articles.

The Software Development Edge – Book Review – Part I

Hear me, I beg. And say thankya, big-big. This one is going to be a hell of long post, but do not worry, you can browse through the cites really fast and get all the essential data you need. My very short summary – go and buy this book, remember (almost) every page, it will do you some good. The software development edge by Joe Marasco should be your holy book, your guidance in the dark realm of leading teams and developing software.

I counted exactly 170 good ideas, worth remembering. Regarding a total count of 370 pages we have a score 170/370 ~ 0.46, which is amazing! It means almost every second page you’ll encounter contains something useful.

As you might guess in my book summary I’ll have to cover over 185 pages of ideas. Since it would take too long to release a complete overview at once I decided to split it up in four parts, each covering around 100 pages of text. The first one ends exactly at page number 100.

For now, here we go – book’s best points, no cites but rephrases:

General

Spend a lot of time talking to your developers, get familiar with details and problems.

Worst combination possible – keenness absence and sloppy management. Mostly, it will lead to programs that don’t work and if they do, not very well.

If you happen to be the team leader, do not easily yield to your superior (of course you should listen and give in in most of the times, but not easily, because your superiors may suggest (due to their unknowingness) unreasonable demands.

Your iterative approach to solving problems: observe, listen, empathize, synthesize, testing, write down.
Observe – look around you. What’s happening? Where could be the source of a problem or maybe it’s symptoms?
Listen – after you’ve located the problem, talk to people and listen to their opinion. Talk less, write more.
Empathize – the clear difference is here to “listen” – while empathizing you not only collect objective data, but also give subjective feedback.
Synthesize – now put all parts together: your objective data while observing and listening, emotional aspects while empathizing, your box of tools for solving problems (should be mostly your experience). The result – a possible approach for the given problem – should be put out to test.
Write down – now you should write down everything that occurs while your approach is doing it’s job. If you don’t do it it will become much harder to convince others to accept your approach. Besides, what’s not written down is soon forgotten.

Doubt everything. Check every partial solution.

In every big project someone, who is on his/her own is a potential danger. However you shouldn’t throw all people in one big basket. Create as little teams as possible with as little members as possible. Four groups three or four members each may be way more productive than an horde of 50 employees.

Sooner or later every leader will have to make choices. If your team members were chosen correctly they will accept your decision because having one is better, than none decision at all. However it doesn’t mean that you are free to come up with any crap idea – you still need to analyze give situation. The only thing to avoid is to be paralyzed.

Goals

The mountain top – the end of your project – should always be the main goal. Everything that hinders you and your team on the way up must be cut off.

On the other hand climbing up in real life is just the half of it, you also need to come down. This can be compared with supporting your existing project – a successful one can be completed and then supported over a long period of time.

Why projects fail

Nonrealistic time schedule

Too many team members, team contains a lot of mediocre developers compared to the best ones.

Neverending stories projects lasting so long, that all requirements change multiple times.

Ignore first iterations’ results. No analyze and change after seeing them.

Lack of clear goal, understandable by everyone

What can lead to success

Small, but smart plan with few details is more effective than plan overloaded with details

Clear your work before requirements change

Correct your movement’s vector (use small iterations) on the fly

Durability – extraordinary peak strength means nothing on the long term

Concentration – your team don’t lose sight of the goal

Management

Don’t hire high skilled people to involve them in trivialities.

Main point of every task should be a client’s problem. Even more important is for your product to generate additional value for your customer (by solving his problems).

Best leaders can project their sense of goal to others – by giving them a good example. Managers make sure that this goal is achieved. Best people out there unit qualities of leaders and managers.

Take care of every small problem in time. Even smallest problems tend to grow massively. This leads to two kinds of bad managers – the “ostrich” ones, who won’t see the problem and the “lazy” guys, who will postpone everything until it’s too late. Don’t be one of them, problems don’t disappear magically.

Do not let you lead easily. Always remember – your goal is to solve a problem, achieve some result, not to make you most popular and well-liked guy in the department.

Don’t panic. Seriously. Be solid as rock. Every crisis will be over, your duty is to participate in solving this crisis, not in overreacting. Be an example for everyone else (rock-solid).

Laugh. Even when facing dumbest customer’s demand, better laugh about it, do it, forget it than making drama.

Teams forgive their managers a lot of things, but laziness, incompetence, lack of reward for efforts and lack of humor are not among them.

Trust your instincts – if you are really feeling uncomfortable with something, trust your inner self, most likely you’ll turn our being right (this also means do not hire people who will make you uncomfortable – in exceptional cases it might be worth the risk).

Developing software

Goals are most likely not where they meant to be. Often because at the beginning the technical requirements are not quite clear und well understood.

During the process people will make mistakes.

Your goal is a moving one.

A good manager will always make a lot of little steps rather than few big ones. This allows to shorten the overall distance because after one misstep you haven’t travelled a big distance and after a dozen steps your next one will most likely be close to optimal.

Do not start with easiest problems. By doing so you’re digging your own grave. Your team won’t bother with upcoming possible risks. Even the easiest task will grow big (there is always room for improvement). This leads to scarcity of time for the real challenge and to one further problem – explaining that you need more time doing the most difficult part, covering the biggest risks is much easier to your superiors than begging for more time because your team was wasting it.

Iterative approach forces you to apply all lessons learned from this project (all previous iterations) to all upcoming iterations of the same project.

 

Happy new energy! This is how you make bitrix work with git.

I wish everyone a pleasant new 2015!

May your business flourish, your apps find new users and your customer forget the number of your technical hotline.

Besides, if you should ever happen to work with 1C-Bitrix framework here are some hints how to befriend it with git. If you just try to plain start developing a Bitrix app under git you may encounter few uncomfortable things – since Bitrix is huge (more than 18000 files) ever commit will take long. In most cases I received plain errors instead of pleasant working.

So here what you should do:

First, add this to your local git config

You may want to play around with the numbers, just keep in mind following:

Larger window sizes may allow your system to process a smaller number of large pack files more quickly. Smaller window sizes will negatively affect performance due to increased calls to the operating system’s memory manager, but may improve performance when accessing a large number of large pack files.

As seen here

So now which files to exclude from bitrix using rather .gitignore or /.git/info/exclude? Of course I can’t tell you where to put your development files, but it is a good practice not to touch those:

Meaning ignoring them is generally a good idea. This will save you a lot of time! Happy coding. (For the record – we’re using GitLab instead of GitHub for reasons of security, however commands are just the same for both of them)

Next book sneak peak

The next one, “The Software Development Edge” by Joe Marasco is finally done. Since I’m continuing my more “scientific” approach on book summarizations this time it turned out to be really extensive. I guess it will take a while to write everything important down.

A little sneak peak on my work regarding this awesome book by Joe Marasco.
A little sneak peak on my work regarding this awesome book by Joe Marasco.

[readolog_blockquote ]One of the main reasons for Joe being able to deliver software in time was his effort to understand every detail of development, every problem occuring, thus, leading to knowledge where you can make right decisions for the whole project movement. This effort is not based upon some kind of magic, but simply upon investing a lot of time in talking with developers.[/readolog_blockquote]

Coders at Work – a book review

So here I finished this work. While being sometimes entertaining, sometimes delivering useful thoughts and sometimes being boring ass stories I found it overall… decent. Just as the last book –  by Robert Glass –  this one falls a little bit after it.

As for now I want to give you a more scientifig approach on rating book if it please you – an idea I grabbed from one of other book’s publisher. I will rate the usefullness of the ideas. How will I perform such a task? Well, clearly subjective, but nevertheless I will try to mark every interesting idea, then divide the amount of pages by the number of interesting ideas. An ideal book may reach far beyond 100% by having multiple impressive text passages… but this percentage rate appears rather imaginary. I guess some values above 20% will indicate a lecture worth your time and thus, reading.

The most appealing thoughs and ideas I will quote directly so you can make a clear picture rather to believe and agree with my view or not. Let’s start with “Coders at Work”.

Short opinion

As with Fallacies by Robert Glass this book comes a bit… outdated. Yes, one should never judge by youth and appear but only by inner values, however reading every chapter (as the author asks almost same questions) about PDP-10, DECsystem-10, IBM 1130 and so on and so forth

Calculating the worth

I started to mark worthy ideas by page number 280. Given the total amount of pages to be 525 it makes 245 pages difference. I counted 13 useful text passages. This leads to 0,0531 or about 5.3%. It may not seem to be very much, thus, leading to a bad overall rate, on the other side, in turn, I liked the thoughts that much, you could easily double the value if you find them impressive too. Since 13 is a good number and not a big one, following you can find all of the parts at once.

Job interviews – seeing the spark

Important on job interviews – it’s not nessesary a good sign if a person can solve logical puzzles. It just shows that they can solve logical puzzles. What is however more important – how attendants deal with technical problems. How do they think? How do they work with someone? Did they do their homework – are the basics on an acceptable level? Can they say “To solve this problem, I need A, B and C. This is how I would use those approaches together (explains it). Maybe I should look up about part C more, but I’m sure this leads us towards a right solution”. Until now you should get a rough idea about the interviewer as a technical specialist. And of course you should ask him or her to write down code on a peace of paper or blackboard. They should know their ABC without Googleing it every time. Additionally they should be – of course – able to work in a team.

Ask people about what they’ve done, what they’re mostly proud about. If they truly went through hell and back for a project they will be passionate about telling you such a story. Let them take the wheel, be initiative. The most important part here is not only letting them tell you what they’ve done, but although how.

If interviewers can’t tell you anything they’re interested in (it has not to be only about professional treats) they probably won’t show any performance in your project either.

Thinking

The ability to think stepwise makes us more adaptable to the outer world. And you don’t need any programming skills for that. There is a difference between – “Oh, our cabinet door won’t close. Let’s take a look – here, a screw is missing” and “Door won’t close. Let’s call someone!”.

Project leading

A good project leader should know the goal – if you are self-confident about what you’re doing it will fall easier for others to accept you and to follow you. This self-confidence widens out to the whole team, whole project which leads to a complete win-win situation for everybody. However be alarmed not to take too much care of everything as it may drive away the motivation – why put any effort in this if it’s all clear anyway – just sit back, relax the reigns in such case.

To put it short – know what you’re doing, don’t interfere, but be technically educated so you can give adequate feedback.

In chapter 14 I encountered again same thoughts. Additionally there was this one – project revisions. Each team member has had to present their part of work. And the goal was to get the part where the declarator wasn’t sure about. Sure, it sounds like an examination at the university, but the clever trick behind it – get company’s best minds to review your work. This is turbo mode help.

Interfaces

The bigger your programs are, the more you need to care about interfaces. How will this connecting link between those two program parts look like? What’s the input? What’s the output? Which part of the task should be solved by which part of the program?

Documentation

Proper documentation should be regarded as the same kind of art as programming itself. Most of the time it’s either too sparse or too filled with unnecessary details. Bringing together right amount of information and in right form takes a lot of time and invested time should be considered same as for writing code.

Good code, bad code

Thrifty definition of good code – if you need to add some functionality, you do it in just one place, while bad code leads you to changing dozens of places.

A bit about talent

In the middle aged reading and writing were regarding as special talents granted only to the chosen. In the beginning of the 20th century same could be said about art – creating films, writing books, making music was a prerogative for selected people. This is why learning about informational technology is important for everyone – like reading and writing earlier. Computers just extend our creational possibilities, enabling more and more people concentrate on what they really like to do.

Optimizing

Don’t be too clever. Sounds harsh? Do not spend weeks or months to increase some algorithm efficiency if this algorithm will only trigger once in a while in your program. You may even do worse by trying your best, since your program will become more and more difficult.

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:

and

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” ]

Facts and Fallacies – trust them or prove them wrong?

Facts and Fallacies of Software Engineering is without a doubt s decent book. It could be even considered as a good book, but I – fully subjectively and emotionally – just cannot do it. While the main thesis can be summarized as following

Programming is too complex to be measurable, deal with it

and while the facts themselves are quite interesting, I can’t get rid of the feeling that the purpose of the whole book was to proclaim the great goodness of the author. It may sound a bit harsh, but reading on almost every page

as shown in blah-blah [Glass, 19xx] or stated in blah-blah [Glass et al., 19xx] etc. etc.

makes me wonder – is there anything besides author’s work that’s worth mentioning? Will ever a book have a chance to be regarded as a reference for our Robert Glass? I doubt that. Additionally a lot of “facts” are based upon own researches or researches of a very small groups, which is not bad per se, but makes statements like “list of derivative requirements grow by 50 times” seem not a great deal trustworthy. Why 50? Why not 49 or 20?

I don’t want to fully degrade the book since it’s nevertheless pretty decent and now I’ll explain why. The answer is pretty simple – some statements are indeed to such an extent obvious that they may be truly regarded as facts. A few of them I’d like to highlight here in a shortened and combined version.

Every project evaluation is made by false people and at wrong time without correcting the vector.

This is basically the essence of all failure. True is, most of the time the work is estimated by managers or even product owners without involving developers at all. In better cases teams play planning poker, but usually it is discarded because it takes so much time “we can’t afford to invest, better start earlier and give us just an estimation”. In 99.99% of the cases your estimation as manager will evolve into a… real value upon which everything will be based. Deadline? You said project will be done in 3 months, so deadline is now+3 months! No one will ever care to adjust the evaluation or, more correctly expressed, care to accept your changes willingly.

The difference between worst and best developers is a big gaping hole, the difference in their salaries, however, not.

First of all here we have numbers telling us (numbers lie, you know?) that the difference is up to 28 times – again, I’m not a big fan of such numbers, but the essence of the statement is quite true – you gain a lot by hiring best people, because the salary you’ll pay to worst people will come back to you twice – you’ll pay more at the end of the day, because you’ll need more of that sort of people and you’ll deliver mediocre products because those people won’t be able to produce good software.

Supporting your software will cost you up to 80% of invested capital.

Glass mentions numbers span between 40% and 80% and whether you agree or not with those numbers, we all can’t deny the fact. It’s simply true, that your every neat customer will come to you after project “is done” and demand – hey, can I have a button here, a function there? Trust me, and if you don’t trust me, trust Glass – this will eat, no, this will devour and annihilate your time.

[schema type=”book” url=”http://www.robertlglass.com/” name=”Facts and Fallacies of Software Engineering” description=”You can trust the facts blindly or try to prove them. Let this short summary be an introduction to this book.” author=”Robert L. Glass” publisher=”Addison Wesley” isbn=”5-93286-092-8″ paperback=”yes” ]