Keeping an Eye on Code Knowledge

by

code-knowledge

In growing companies, as software systems become complex and extensively engineered, maintenance can be a challenging problem. Moreover, when high profile bugs arise and/or a lack of system availability arises, it can have disruptive consequences on a business. Hence there is little room for mistakes in these crucial systems.

To ensure reliability and quality, working on software robustness is key to success, and many different strategies have been developed over the years. Things like test coverage, documentation, branching, deployment strategies etc. are typically strictly regulated and engineered to minimize risks and maintain high development efficiency as well as quality.

Nevertheless, while many development techniques keep getting more and more engineered and standardized, I couldn’t help noticing that others didn’t keep up on the same pace in their evolution. In particular to me, a yet unexplored area is code knowledge, which is in short how well engineers know the system they are working on.

Code knowledge can be very important in many real cases. In an ideal world having two engineers with the same experience, one having written the code he is working on and the other one being new to it, working on a code that is very well tested, well written and well documented, would probably not lead to a much different outcome. However, in real cases much larger gaps can be noticed in their efficiency.

Not only it would be much slower for a developer trying to learn a code base by reverse engineering and guessing with respect to being able to ask questions to other developers that already know the code, but more importantly it would be error prone.

The reason for this is that many subtle technical constraints that arise while developing the system can’t always kept in documents or be self-explanatory, so they only reside in the heads of those people who developed the system. Accordingly, the risk in which many companies incur is that when those people that hold knowledge leave, then the knowledge just gets lost and newcomers who are unaware of those constraints introduce regressions while developing, sometimes creating more damage than benefits.

So how can companies minimize the risk? What is the best arrangement of developers that provides a good level of collaboration, reducing the ramp up period for developers that are learning specific part of the code and guarantees a barrier against mistakes and regressions?

Although an exact answer would be complicated to determine, a rudimentary suggestion that I would give to companies to help prevent burying technical knowledge would be for each logical component of the code to have at least two knowledgeable people available at all times, in such a way that as soon as someone rolls off there is someone else able to fill in.

And an even better plan is to invest time in thinking through a policy that not only aims to allocate engineers to different projects in a way that allows them to move ahead faster today, but also aims to be resilient to unexpected future changes. Bad staffing plans do bite back.

Mastering the Art of Client Communication

by

g1384740369505006881

At some companies, designers and developers have little to no interaction with clients or customers. It’s not uncommon for the people working on a project to be walled off from clients by account managers or customer service. At Grio, every designer and developer is client facing, and everyone ends up doing some of the work that is traditionally done by an account manager, such as managing day to day contacts, relationship management, and responding to problems & issues.

We know that good communication skills are key to building strong client relationships, which leads to repeat customers. As the person on the front lines, the designer or developer is the closest to any issues with the client, and is also in the best position to help mitigate those issues. Good communication can help keep small problems from turning into bigger problems.

Over the years, Grio has put together the following rules of client communication.

  1. Put yourself in the client’s shoes
  2. Always provide a recommendation
  3. Address client complaints proactively
  4. Escalate issues ASAP
  5. Overcommunicate
  6. Communicate professionally

Following these rules – and learning from our experience! – can help you maintain excellent client relationships.

Put yourself in the client’s shoes  

In order to serve clients better we need to understand their needs. First, this involves listening – what problem is the client trying to solve? What pressures are affecting their business?

Understanding the client’s business goals will let us serve them better.  Its also important to remember that clients have various pressures from their own organizations and investors, and so their goals may not always be what we would assume. Listen carefully to what the client’s needs really are and make sure that everyone is on the same page about how to meet their goals.

Always Provide a Recommendation

Clients often come to us with requests and proposals that we either can’t implement or don’t think are a good idea. If you disagree with a client’s proposal, it’s important to let them know not only why you disagree, but also what else can be done that will meet the their needs. We never want to respond with only “No, we can’t do that” – we always let clients know what we can do that will help them solve their problem. We never want clients to be left guessing or not knowing how a problem is going to be solved.

I’ve often found that clients will start out by proposing a solution instead of telling you their problem – sometimes the reasoning & business needs behind their requests needs to be teased out. For example, a client might come to us with a request like “I want you to make the login button bright red and blinking” instead of telling us the real problem, that they don’t think users are finding the login button.  Once we understand the real problem, we can work together with the client to find the best solution. This is where a company like Grio gets a chance to really differentiate ourselves as ‘consultants’ rather than just ‘contractors’ – our job is to be the client’s guide, and to give them our professional recommendation as experts in the field.

Ultimately it is the client’s product and their decision, and even when we give them our best recommendations backed up by the soundest arguments, sometimes they decide not to go with our recommendations and make a decision we think is wrong. It’s important not to take this personally and remember that it happens all the time – accept it and move on to the next thing.

Address client complaints proactively

If a project or deliverable is going to be late or a goal isn’t going to be met, let the client know as soon as possible. If something doesn’t work as expected, or is slow, or has bugs – let the client know that and what steps you are taking to address the issues.  Whenever you know about a problem in a product, try to be the one to point it out first – don’t hope they won’t notice.

Escalate any issues as soon as possible

Every project at Grio has an account manager and a project manager*. Project managers are responsible for keeping the project on track, account managers are responsible for keeping the client relationship on track. Project managers and account managers need to know as soon as possible if there are any problems on a project. Whenever an issue arises with a project, the project manager needs to know as soon as possible so they can help to address it with the client, and if necessary bring in the account manager as well.

  • On a smaller project with only 1 or 2 people the “Project Manager” role may be filled by developers or designers working on the project.

Over-communicate

Frequent updates help put clients at ease about their project’s progress. We never like to let more than a couple of days go by without giving the client an update on the project.  If you feel like you are communicating too much, then you are probably communicating at the right level. If things with the project are not going well or the project is getting close to a release, communicate even more frequently, at least once and possibly multiple times per day.

Be careful about overusing industry buzzwords that a non-technical client might not know. For example, saying “A design that adjusts for both mobile and web” is just as easy as saying “Responsive design”, but clients who are not as familiar with web development might not know what “responsive design” means. Be sure to explain more technical terms in plain language without using too many acronyms and buzzwords.

Also, beware of over-reliance on IM & email – these are invaluable tools, but they can be dangerous when communication starts to break down. A fast response to a skimmed email or IM can further escalate a problem.  If misunderstandings start to arise or there seems to be a disagreement, pick up the phone, or reply with a request to set up a time to talk about the issue. When multiple emails are going back and forth, a phone conversation is usually a much faster way to get everyone back on the same page.

When possible, try to set up at least one face-to-face meeting with the client during the course of a project. Face-to-face meetings are a great way to get the information you need while building a rapport with clients.

Communicate professionally

Professional emails use good grammar, proper punctuation, and have a signature at the bottom with your company name, email address, and other contact information. You might not think that people will judge your work by how you write emails, but they will, even if it is not conscious. Sloppy looking emails can communicate “this person is sloppy, maybe they do sloppy work”.  In addition, poorly written emails are harder to read and understand, so clients may only skim your emails and not fully grasp what you are saying, leading to possible misunderstandings. Always proof-read an email before you send it off to a client to make sure you are presenting yourself as professionally as possible. If you aren’t confident in your writing for any reason, have someone whose opinion you trust look over your email before you send it.

It’s fine to say “I don’t know”

Finally, it’s fine to say “I don’t know” when a client asks a question that you don’t know the answer to. Sometimes people can become flummoxed when asked a question by a client that they don’t know the answer to – remember that no one knows everything, and if you don’t know the answer to a client question, it’s fine to say so.  Some other phrases you can user are “I need to double-check on that.” or “I need to do some research to answer that” or “I need to look into that and get back to you”.  A confident “I don’t know, but I’m going to find out” sounds much better than a wishy-washy “well…I think…it could be…maybe…” – just say I don’t know, find out, and follow up!

Hopefully these tips can help make your next project run more smoothly than ever. Do you have some additional tips or rules that you use? Feel free to share them with us in the comments.

Late Subscribing and Polling APIs with RxAndroid

by

6407041

Howdy, lazy bum! Enjoying the ReactiveX magic? Want to take a look at polling?

I’ll be walking you through a solution I put together for one of our up and coming apps! It works rather well, I learned a lot, and so far no complaints…although there are no users yet either!

Feeling quite charitable, I’m going to let you in on some useful bits and pieces as we build up to polling: threading, late subscribing, replay, manual re-triggering and error handling (a must for preserving replays).

Prototyping with P5

by

ttthingy

When I wanted to create a proof of a concept project for one of the game ideas I had, I found many tools and gaming frameworks. However, most of them had a steep learning curve which required a significant time investment before the game could be played. Then I discovered P5, a Javascript library inspired by the Processing language, which made it very easy to get started.

Benchmarking Intel i5 & i7 Processors

by

core2_underside

What is benchmarking?

 Benchmarking is the process of measuring performance for a piece of technology against other pieces of technology. Typically, processors are benchmarked by running programs and software that heavily taxes the system. This allows the processor to truly shine (or, possibly, the opposite). For the purposes of this post, the i5 and i7 processors’ performance were measured in five different categories, each using one test:

Bundler Bulkheads for Rails on Docker

by

rainbow_720

As part of my exploration of a minimum set of devops tools, I’ve been learning how to stack containers full of Rails apps onto the Docker. There are plenty of examples of how to get started with Rails and Postgres on Docker, even one from the whale’s mouth, as it were. Working from this example, it was pretty clear to me that one of Docker’s major strengths is that it makes it really, really easy to get something running with a minimum of fuss; it took all of about a half day to learn enough Docker to hoist anchor, and even tweak a few things to my liking. One thing kept nagging me about the Docker example, though, and that was a warning from bundler when running docker-compose.

UX Sketches: When to Share and When to Keep Them to Yourself

by

Sketched wireframes are a catalyst for conversation with developers. During implementation developers continue to communicate with design as questions arise.

Why Sketch?

One of the great things about Grio is that designers and developers often work together on projects. We have lunch together and tell each other jokes while collaborating to solve challenging problems brought to us by our clients. Some projects come with constraints that force the team to be savvy in the way we produce deliverables. As a result, sketches and sketched wireframes are often a suggested deliverable.

Content Delivery in P2P networks

by

p2p-image

Scalability is a hot topic, especially in Content Delivery Networks (CDN) where scalability, robustness and availability are crucial. A CDN is a system that has the aim to deliver Web content, such as videos, images, and any other type, to end users. Content providers such as media companies need to deliver their content with high availability and high performance, and CDNs offer them the infrastructure to do it. There are different approaches, each one with its advantages and flaws.