West Bridge

I was telling you in the previous post about the XY problem, when someone asks for what they think is the solution to the problem, instead of the actual problem. Well, besides the 5 whys technique, when you are the helper or asking smart questions when you need help, there is one other thing that you can do and it just might help you more than you think.

Rubber ducks are not only good for taking baths, they can also help you with your problem solving or your programming. Of course, you don’t have to use a rubber duck – if you think your teddy bear can ace a duck in a programming contest, go ahead and use the teddy bear.

Don’t think that your duck or bear will magically start spilling out programming advice – they have more of a coaching position – they do not tell you what to do and you will have to find the solution yourself, but they will help and they help by just being the great listeners inanimate objects are.

I will bet this happened to you before: someone comes with a problem and they ask for your help. And as they start telling you about their problem, they will have an “aha” moment and figure out how to solve the problem by themselves.

Taken from “The Pragmatic Programmer” by Andrew Hunt and David Thomas, this approach works because one of the best ways to understand a problem is to try to explain it to someone. Especially when that someone is a rubber duck – you will try harder to explain in detail than you would explaining it to a fellow programmer.

At the end, I will also provide the easy steps one should take in order to successfully employ rubber duck debugging or programming (taken from here) they were just too good not to mention:

Step 1) Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety)

Step 2) Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.

Step 3) Explain to the duck what your code is supposed to do, and then go into detail and explain your code line by line

Step 4) At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

Ever heard about the XY problem? Well, quoting from a site dedicated to this, “the XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help.”

And the XY problem is more common than you might think – I was telling my girlfriend some weeks ago about the XY problem and she went: that is exactly what happened to me today! One of her colleagues asked for her help in finding an internal reference number for an invoice. So my girlfriend pulled a copy of the invoice from one of the systems, using information from the invoice copy she tried to track down that internal reference that was not really used by people in her department in another system and after some time she asked her colleague: but why do you need that internal reference number? So I can retrieve a copy of the invoice, the colleague said. If the colleague had stated from the start what she wanted – the invoice copy – instead of asking about a reference that she thought would help her retrieve the invoice, it would have not wasted unnecessary time for both of them.

And that happened in a finance environment, but it happens even more often in software development. I actually got to hear about the XY problem from our CTO who has had a fair share of XY questions received from the developers.

In my opinion, something that can be used (besides the solutions on the XY problem site) is the 5 whys technique, used in process improvement. Used to determine the root cause of a defect or problem by repeating the question “Why?” several times (you do not have to ask the question exactly 5 times, can be less or more) I think it can also be used here, without even having to ask to many times the why, as when you do when using it in process improvement – it might just take one why to find out the X of the problem instead of the Y.

On the difficulties of estimating and keeping the project within the proposed time frame, the following “programming pearl” was published in 1985 and belongs to Tom Cargill of Bell Labs: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.“ Hopefully, your estimate will not be off by 80%, but this is a quote you should always remember when estimating projects.

On the same page with the first quote, a self-referential one, coming from the book Gödel, Escher, Bach: An Eternal Golden Braid (isn’t that an impressive title for a book?) by Douglas Hofstadter, here it is the Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” Why people tend to think that it will take less to complete a project than it actually does? Probably because of the optimism bias – a cognitive bias that causes a person to believe that they are less at risk of experiencing a negative event compared to others.

For projects that are late, it would seem a good idea is to add more people to the project. Well, it’s not. In “The Mythical Man-Month”, Fred Brooks states the Brook’s Law: “Adding manpower to a late software project makes it later.” Derived from his first hand experiences while working at IBM, Brooks became so dissatisfied with people repeating his mistakes over and over again that he said his book is like the “The Bible of Software Engineering” because “everybody quotes it, some people read it, and a few people go by it”. Wait, what, was I just doing that?!

C.N. Parkinson, a British historian but who touched also public administration and management subjects in his books, came up with a few laws, including the one bearing his name, Parkinson’s Law: “Work expands to fill the time available.” So be careful with lax deadlines and estimates, because most times it will not translate into work being ready ahead of the deadline, as you would expect, but it will be actually contra-productive.

The Stock–Sanford corollary to Parkinson’s law states that: “If you wait until the last minute, it only takes a minute to do.” So go ahead and cut those deadlines (at least your personal ones), not to a minute, but maybe in half as recommended in this Lifehack article.

And I will end with the last law for today, Golub’s Second Law of Computerdom, a law that states why carefully planning a project is important: “A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.”

It’s time for a little discussion about time! Well, actually about time and materials because when it comes to project pricing in software development, there are two main approaches: Fixed price and Time and Materials.

If we go over to Wikipedia , we will find out that “a fixed-price contract is a type of contract where the payment amount does not depend on resources used or time expended” and it is similar to many of our dealings in the day to day life when we buy something – it is clear what we want, it is clear what we are buying and the price is also known upfront.

This approach works well for consecutive projects that are very similar to each other, are clearly defined by the customer and the supplier did the same kind of project over and over again. That means fixed prices contracts are suitable for, let’s say, installing a pool in your backyard – the scope of the project and the customer’s expectations are clear, hopefully the supplier did the same kind of work several times before, so the supplier knows how long it will take and how much it will cost to fulfill the order.

That also means that fixed price does not work that well in software development. Why? Because software development can be unpredictable. Most of the times, you know the deliverables (although these can change and sometimes it can be beneficial for the customer to be changed from a business point of view) but the path to those deliverables is not a clear path and software development is more of a exploratory work than a clear–cut one.

In a Time and Materials contract (thanks once again to Wikipedia ) “the employer agrees to pay the contractor based upon the time spent by the contractor’s employees and subcontractors employees to perform the work, and for materials used in the construction (plus the contractor’s mark up), no matter how much work is required to complete construction.”

This does not mean that estimates should not be given and it also does not mean that the development company can just keep on billing endlessly without delivering a product. That is why it is a good idea to combine this approach with Agile practices because after each iteration working software can be delivered to the customer.

The relationship will be a flexible one: if the customer will want to change the scope or add new features, the contractor will be happy to oblige. In a fixed price contract scope creep (the customer adding requirements along the way) is one of the concerns for the development company and can lead to a tensed relationship between customer and developer.

Both approaches have their strengths and weaknesses – the fixed price contracts may look more appealing to the customer, because it seems that the risk and the budget is known upfront, but the customer must not forget that in order to have a fixed price contract work out fine, the customer should invest time even before starting the project in order to exhaustively define requirements and expectations. Also, sometimes correctly estimating a large software project is something nearly impossible and you can have a look at some of the big failed projects here .

The bottom line is this: in software development, the vast majority of projects cannot be clearly defined to the smallest detail upfront and that means a fixed price contract will be nothing more than a coin flip when it takes to taking the risks and the potential losses – both the customer and the developer will hope they get lucky and that just does not sound to me like good business practices.

Or is your site an old time grouch who refuses to make new friends and display properly on mobile devices?

If you had a site 10 years ago, being able to be seen on a mobile device was a thought probably not occurring to you. 10 years ago, people were worried if their site was displayed properly on all desktop browsers or they were fiddling with Flash, trying to implement animations and increase user interaction.

But now, in 2015, the question in the title is one you will have to ask yourself: is my website mobile friendly? Hopefully, the answer will be a yes and not a no. But if you don’t know at all what the answer is, Good’Ol Google can help you with finding out. Use Google Mobile-Friendly Test tool and check if your site is mobile or not.

You have the question and if you did not already have the answer, with Google’s help, you now also have the answer. But why is this information relevant to you?

Well, it is relevant thanks to… once again, Google. Starting April 2015, Google thinks that “when it comes to search on mobile devices, users should get the most relevant and timely results, no matter if the information lives on mobile-friendly web pages or apps” and that is why they took two measures: expanding their use of mobile-friendliness as a ranking signal and they began to use information from indexed apps as a factor in ranking for signed-in users who have the app installed – you can read more about this in Google’s official announcement: Finding more mobile-friendly search results.

Long story short, for mobile initiated Google searches, your site will appear higher in the search results if the site is mobile friendly and lower if not. Why should you care? Well, according to Google, back in May 2015, in ten countries, including USA and Japan, more Google searches are performed on mobile devices than on desktop computers.

The trend was clear and it was once again confirmed when on the October 28th, Google’s Amit Singhal, senior vice president of search, announced: “For the first time, we’re getting more searches on mobile devices than on desktop”.

So, if you add up all this information, the larger picture reveals itself: more than the 50% of your potential customers are searching for your business on the internet by using mobile devices. And if your site is not mobile friendly, those potential customers might just go to your competitors’ mobile sites and who could blame them? They just might rank higher in the Google search results.

I am Stefan Ghimpau and I am a project manager here, at West Bridge, overseeing Android and web development projects and now also the resident blogger. I have always enjoyed writing but this will be the first time I will be writing on IT or business related topics. I love reading up on anything of interest to me, either personal or professional, because I think people should never stop learning and growing. Hopefully, all this information I soak up on a daily basis will allow me to write posts you will find interesting and useful. And please, feel at home here and if you have anything you would like to add you can comment on the posts or use the contact form to send us a message.

If you did not get the chance to read the About Us section of our site, we are a Romanian software company, based in Bucharest but our largest projects were developed for US based companies. While we handled large projects, we are not a large company and both us and our customers like it that way. And the reason why is pretty simple, as you will see below.

Imagine yourself driving a big truck every day, from home to work and then back home in the evening. Imagine going shopping and having to park that big truck of yours in those tiny little parking spots. Or maybe going on a Sunday for a couple of hot laps in your truck on a circuit, if you are a weekend racer.

Well, that is what it feels like developing software solutions with a large company.

But here, at West Bridge, we are agile. We are nimble, we are fast. We are not a truck, we are a sports car. And you might ask, oh, but what about those times when you need something more for your project? Well, small does not mean not scalable. If your project requires it, we can ensure scalability – after all, we are located in one of the best places in the world to do so, in Romania, where competent, hardworking developers are just around the corner. But scalability does not have to mean getting larger, getting heavier or bulkier – it means upgrading and fine tuning. Adding horse power and better components, not increasing size.

They say that a good start is half the work. Would you rather hit the gas at the green light for your project in a truck or in a sports car?