Skip to main content

Our Insights

The team list

Building a team? We got you. Get the best tips and how-to´s weekly on your inbox.

Since their inception, we’ve been told several times that Containers are better than Virtual Machines. Now...

Since their inception, we’ve been told several times that Containers are better than Virtual Machines. Now, I’m here to tell you they don’t. Docker Containers aren’t better or worse than Virtual Machines(VMs) but in my experience, the latter is much better. Let me tell you why.

Why Are They Useful?

First of all, let’s recall why these two virtualization tools are very convenient for developers and IT.

In software development teams, many times happens that a team member needs to install the software in a different OS than the application is run.

Software running on an Ubuntu Server might be develop in a MacOS computer. Installing stuff in MacOS is way different than in Ubuntu and this can cause trouble for developers when trying to run their applications in development mode.

This is where virtualization comes in play. You setup a virtual machine with all necessary dependencies for your software to run and then give the configuration files to developers and with a few commands you can have a proper development environment regardless the computer or operating system.

You now have portable and reproducible environment for many OS.

Docker Containers serve this purpose as well but they do it in a different and more performant way.

Docker Containers vs Virtual Machines

One of the main differences between these two kind of virtualization tools is that virtual machines might need more HDD space upfront, are slower to build up, and can be slower to boot up.

Containers consume less disk space (it depends), are faster to build up, and are faster to launch.

One could say containers are the best of the best. Tools such as Kubernetes might prove it right and definitely, they have a solid ecosystem and use case.

But what I see is that from the IT or DevOps perspective, they might be awesome but in Developer Experience, they’re not.

The following are the reasons why I believe Virtual Machines are better than Docker Containers. They’re mostly based on good personal experience in projects where servers were Virtual Machines and not so good projects deployed in a container solution.

Find Host or Container

With Virtual Machines, whenever you need to debug or test something in a cloud environment, you just need to ssh into a given IP address and that’s it.

When using Docker Containers you’d have to first get the IP address of the Docker Host and then find the specific container the application was deployed to.

If you have several Docker Hosts, and your app is deployed to several containers, then good luck finding the right container in the right host.

Of course, this can be solved with a script. Code (or have someone to do it for you) a script that:

  • Loops through the IP addresses
  • Run docker ps
  • Grep the output and look for the container ID
  • Continue until there’s a match
  • If there’s a match, run docker container exec
  • Do your debugging

What a PITA. Now, you have this script and you think you won’t have any more problems. Well, what about rotating IP addresses for security reasons?

This is why I think Virtual Machines are better than Docker Containers. In a cloud environment, accessing a virtual machine is WAY easier than just finding a given container.

File Uploading

Imagine you are handed a new feature to build. You have to upload files to a file storage. You think about your users so you set the upload to be run in the background because uploading a file might take some time.

You build it, test it, and try it locally. It works on your machine.

If you push this feature to a Virtual Machine deployed web app, well, it’s going to work fine. If you deploy it to a Docker Containers deployed web app, it won’t.

Why? Keep reading.

In the containerization world, one container regards one task, so that they’re small, reproducible, and fast.

With this in mind, your application container only regards running your code NOT running background jobs. So, if you have background jobs running in a different container, the file upload feature won’t work because the uploaded file won’t exist in the background job container.

Let me slow down:

  • App container: runs code and has its own file system.
  • Background job container: runs code in background way and has its own file system.
  • App container: receives uploaded file via form in web browser.
  • Background job container: picks file in the expected folder but it won’t exists because…

The key here is file system differences. The App container file system is not the same as the Background job container file system. When the App container receives the file, it is stored in a temporal path. As this path or folder is not in the Background job directories, the file won’t be found nor uploaded.

And now we have a situation. We either use some kind of Docker Volume or leave the feature as a synchronous one. In my case, I left the feature to work in a synchronous mode.

This is another reason I think Virtual Machines are better than Docker Containers.

Docker Alpine

Previously, I mentioned Docker Containers are a good alternative to Virtual Machines because they consume less disk space. Well, this might not be 100% true.

It happens that before a container you need a Docker Image. A Docker Image is like a base artifact that describes all the things the container will have when is run. With a Docker Image you indicate the container operating system, installed software, environment variables, configured files, and command to execute.

Similar to Virtual Machines images, Docker Images consume disk space. If you’re not careful enough you’ll end up using all your HDD space. You have be mindful about the base image you use to build your images, what dependencies are downloaded, and know a few key points to use less disk space as possible when building your images.

In the end, for the developer who only wants a portable environment, this make no difference than using a virtual machine.

This is when Docker Alpine steps in. What’s Docker Alpine? It’s a Docker Image that has all important stuff to run Linux and leaves out everything that is no strictly required.

By using Alpine, you can really create slim Docker Images. It brings the benefit that your images will build faster, your containers will be build much faster, and you’ll use less disk space.

Of course, it comes with its own set of problems. I experienced one of them.

Generating PDF Files with WKHTMLTOPDF

WKHTMLTOPDF is a tool to generate PDF file out of HTML content. It’s really useful because you can reuse HTML files and their styling. PDF generation is a complicated domain and WKHTMLTOPDF helps a lot to simplify.

If your software is installed in a Ubuntu server, you’ll be more than fine as many of the WKHTMLTOPDF dependencies are already available in the OS. However, when your software is being deployed to a Docker Container based on Docker Alpine, you’ll run into problems.

In this situation, Docker Alpine is going to be troublesome. Nothing big but it’s bothersome.

In the end, to solve this issue with Docker Alpine I had to read through GitHub issues, read more, and try many options to see what worked and what didn’t. In order to make the tool work in the Docker Containers I had to installed several missing dependencies, more dependencies, and finally WKHTMLTOPDF.

All that trouble could’ve been avoided with Virtual Machines. It wasn’t the first time I used WKHTMLTOPDF. I even have a set of scripts to installed it. They’ve always worked in Ubuntu operating systems. They didn’t work in Docker Alpine.

Not that I’m saying that Docker Alpine is bad. It’s just very different and might cause trouble. But this is also a point I think Virtual Machines are better than Docker Containers.

You might think to yourselves these points are only valid to me because they’re personal experiences. You’re right.

I’m not saying Virtual Machines will always be better than Docker Containers. The message here is that VMs have been great all those times I used and needed them. Containers are cool, of course, are performant, and small. Sure. But in regards of Developer Experience, Virtual Machines have still many good stuff to offer.

From my viewpoint Virtual Machines > Docker Containers.

Does anyone know why we learned to recite the periodic table of elements by memory? Do you even recall...

Does anyone know why we learned to recite the periodic table of elements by memory? Do you even recall what “Sm” stands for? Yes, there are a lot of useless things we learn through our lives and that’s how I used to feel about Burndown charts until recent weeks. Now that I know the true meaning and how useful they are,  Burndown charts have become one of my most precious tools in Project Management.

So, what the heck is it?

A Burndown Chart is the graphic representation of your team’s velocity, it shows how quickly (or slowly) the team is working through the sprint’s user stories. So, it compares the total effort of the team against the amount of work for each iteration (sprint).

The Burndown chart should be shared regularly during the sprint so everyone can notice the progress and tell whether or not they will be able to complete the sprint and, of course, taking action to ensure this.

But, how should you read it?

First, you will need to recall about cartesian planes, x-axis and y-axis. For burndown charts this is what each one means:

  • X-axis (Horizontal): This is the timeline, usually the days that have passed from the beginning of your sprint.
  • Y-axis (Vertical):  This is the work that needs to be done by using the remaining time estimate (that’s why we need to estimate tasks as most accurately as possible).

Start with good estimates

The product manager has given you a feature, and now you need to estimate. Don’t guesstimate, make your best to do it as accurately as possible. How? Try this: 

  • Don’t wait until grooming to read the documentation, read it in advance
  • Ask a lot of questions
  • Ask for designs, and if not, call out this may impact your estimate
  • Clarify the scope/restrictions and make sure everyone is aware 
  • If you don’t feel sure, better not accept it

How do the burned tasks get burned?

The chart uses closed tasks for decreasing the remaining effort, but, what’s a closed task? This you will need to set it up. Most of the PM tools have a scrum board with configurable columns which you can locate task statuses (To Do, In Progress and Done). Whenever you move a task to that Done column, your Burndown chart will show less value for the remaining tasks. The goal is to get to zero at the end of your sprint.

Burndown charts need two key items from your sprint: estimates and Done tickets, this combination will set up your sprint for success or not. Make sure you estimate accurately with enough information, set up your PM tool to identify a really closed task, this way you can rely on your Burndown chart to tell the feasibility of completing your sprint on time.

Whether you are starting out a new project or simply adding features to an existing one, there is a critical step...

Whether you are starting out a new project or simply adding features to an existing one, there is a critical step in the process which usually causes some friction: the “Handoff”. It is considered the action of passing over the current state of the project’s design to the engineering team so the development process can start.

And that couldn’t be any more wrong.

What is commonly seen as a baton pass in a relay race should actually be compared more to a rugby match, where the team runs at the same time, backing up whoever is leading the charge. In this blog post we are considering the term design not only as UI or UX but as an architectural concept where the team designs collaboratively instead of only waiting for the designer’s input. Getting used to this idea of design as a team is not an easy task, here are some tips that can help you implement this format: 

Handoffs? More like Hands-on

Design doesn’t end when development starts, and development shouldn’t start when design is delivered. The Handoff is not the finish line, it is the road. Start collaborating with your team as early as possible, let them know what is on your mind. You can ask your team some of these questions to begin the designer-to-developer flow:

  • Are there any back-end or front-end constraints that I should know of?
  • What are the main points the development team is going to work on first?
  • Is there anything I can share from the start that the team can use as a base?

Speak the same language

Agree on the terms used for the key concepts of the design, by getting team members to acknowledge the established terminology: Components or Widgets, Sliders or Carrousels, Toggles or Switches, etc. This way you’re making sure everyone’s using the same language. Optional: capture this in a document and share it with all the members of the team, this way it will be easier to remember these key concepts using the proper terms.

Check your team’s work – and yours

Most designers will usually agree that their role is to assure the frontend honors the constraints established by the design. You are more than just a supervisor, you should be also willing to constructively critique your own work. Be the first one to notice if what you delivered meets the expectations, even if your client has already approved it. What truly makes a product shine is not how fast and easy the design can be built, but the ability to evolve and adapt to the feedback given by all parties involved. Your first reviewers will be the developers, they are going to share their opinions and most likely will point out flaws that need to be fixed in order to make the design more scalable and re-usable. Take advantage of these opportunities to get closer to the best version of your design.

Prototypes are not almighty

Even if you create a functional prototype, it is hard to visualize the flow between all the parts of a completed design. Only when implementation starts, we can appreciate how things behave when they are connected and sharing data among them. These transactions are part of the design process too and because they are not logical until the components are alive, it is hard to detect those edge-cases that will mostly appear during a QA session. You’ll most likely have to redesign and adapt to these changes – and that’s perfectly fine. Regardless of your experience designing, you’re still human, and you can’t possibly know everything from the go.

Get familiar with your team’s work

You certainly do not need to know what is the difference between Angular and React to create a great UI design, but it will indeed help you and the project to have a better understanding of how much that 3D parallax video slider you’re designing is going to slow development down. Also, you don’t need to ask developers about everything, there is a trick to this: when you are designing something, think of how a user is going to interact with it. Is it easy to explain without moving your hands? If you didn’t immediately think “yes”, ask your nearest front-end buddy about it.

Think easy design

Your development team will be thankful not only for not adding shadows, bezels and opacities to everything, but in the long run, a simple, easy to develop design is going to be easier to polish as well. This reflects in a nicely built interface and a better user experience. Short reminder, if your design can’t be built, it won’t meet any user needs.

 

While this is not a design guidebook, there are a few last words on the topic that deserve being written: working in a comprehensive environment is not only good for the product you are building, but also healthy for the human beings working on it. We get stressed and tired when things are not clear, so even if it takes longer, even if you’d rather not be bothersome, always take some time to make sure everyone is on the same track regarding your design. Think of your team as part of the great user experience you want to achieve because, as a matter of fact, they are.

 

Communicating with your distributed / nearshore team should not be a hassle. By setting up the right...

Communicating with your distributed / nearshore team should not be a hassle. By setting up the right tools and culture you can make collaboration a breeze.

In fact, collaboration can be much easier even than walking down the hall to interrupt Bob and ask him if he is going to meet a deadline. Poor Bob, he’s been interrupted and now out of his zone. Once Bob returns to his original work, it will take him approximately 25 minutes to return to that task, according to research by the University of California, Irvine.

If you haven’t worked with a distributed or nearshore team before, expect it to be a completely different dynamic than having an in-house only team. What should you expect?

  • Less distractions: Remote teams are prone to less office distractions and constant interruptions
  • Online only: The majority of communication happens online via tools, email or video conferences
  • More visibility: Remote teams are compelled to constantly communicate and share progress with tools like Jira and Trello
  • Less meetings: Less impromptu meetings and more efficiency to get the job done
  • Different locations: you and your team have to overcome the fact that no face to face conversations or small talk happen.
  • Bonding: expect to actively have to make the time for 1:1’s, casual talk, etc. to engage with your team.

It is important that you create the right culture and set appropriate team expectations to reap the benefits and maximize the potential of your distributed team. To help guide you with engaging a distributed / remote team, here are some recommendations we provide our partners to support them through a successful transition:

First, create the right culture

Setting up the right culture is often overlooked. Don’t expect the right flow of information, collaboration and deliverables if your team doesn’t know how to interact with each other. This is why setting up the right culture is a crucial step that makes the difference between a successful and a struggling remote team.

These are our seven culture recommendations that should be both communicated and documented for your team to always have access to:

  1. Share your org structure: identify who is who and who reports to who.
  2. Communication channels: define what tools you are going to use and how to properly use them. When to send an email, when to use real time chat and when to set up a video call.
  3. Encourage over-communication: by the nature of being remote you don’t have instant access to your team or a casual face to face down the hall. You and your team need a culture of over-communication. A few examples: acknowledge ALL received messages, set ETAs, participate in both work and “watercooler” chats/channels, give status updates, say Hi as your work day starts, ask for help, the list goes on.
  4. Accountability & Visibility: hold your team accountable by expecting them not only to stick to plans/roadmap but also by using the right tools, everyday. Visibility is key for the success of a remote team.
  5. Connect: We are all human, and as such, need to feel connected and involved. Inspire a culture of getting to know each other, create “random” or “watercooler” chat channels, hold at least 1 yearly get together (2 is best). In general, learn about your team, ask them to do the same. Connect & offer help when needed.
  6. Share decisions: Key decisions should not be kept between two team members. Adopt a culture of making decisions in either group chats and/or widely sharing via email or a team knowledge base.
  7. Respect boundaries: Remote teams also have working hours, we are still people with families and a life outside of work. Create a culture of respect, well planned and calm work.

Second, set up the right tools

There are 4 key groups of tools/software that you need to successfully engage with your remote team. These are:

  • Asynchronous communication: tools such as email, knowledge bases, online documents, etc.
  • Synchronous communication: live chat, video conference, etc
  • Project management tools: these help you manage tasks, timelines, deliverables and documentation.
  • Specialized tools: those specialized tools used by different (departments, specializations) within your team: repositories, hosting, design tools, etc.

For all of the categories above, there are literally hundreds of tools available online that you can set up very quickly. But how do you choose? Which are the best ones? It can be a daunting task.

Our recommendation is always simple: use widely adopted tools that are geared towards remote collaboration. For guidance, these are the tools that have become our standard set:

Asynchronous communication: Gmail, Wikit

Synchronous communication: Slack for real time chat and Zoom for video calls

Project management: Notion, Jira or Basecamp

Specialized tools:

Design: Figma

Development: let the team pick their stack or use your current one

Third, set the standard

By creating the right culture and providing your team with the right tools you are setting up your remote team towards the path of success. But that is not enough, now it needs to become part of your daily routine.

Set the standard by establishing the bar, and executing by example. This is the most important part of a successful remote endeavor. Set expectations and support your team in making it part of your culture.

Here are a few key items that you and your team should keep in mind everyday:

  • Use the appropriate communication channels
  • Widely share decisions
  • Acknowledge ALL received messages
  • Share (and meet) deadlines and ETAs
  • Respect boundaries and working hours
  • Keep a team knowledge base/wiki for important decisions, processes and documentation
  • Provide thorough and thoughtful responses when responding

I’ve been working with and setting up remote teams for over 10 years, I’ve seen what makes them tick and what causes them to fail. These points have become our standard at Ideaware because we experience, on a daily basis, how they work.

If you have any questions or need any help with your remote team, feel free to email me: max@ideaware.co

 

My oldest son used to be very difficult when he had to try new things, or, that’s what we thought. He got...

My oldest son used to be very difficult when he had to try new things, or, that’s what we thought. He got angry and impatient when he didn’t know our next steps and the whole agenda of the day. So we decided to keep him informed about EVERYTHING we were planning to do and, guess what, we won and he is a very calm boy now. While trying to handle that anxiety of him, we understood anticipation, information and managing his expectations was the key. Sounds familiar? Grown-ups need that and so do our clients.

To make your client happy always inform, work together and set the right expectations off the bat. A happy client is an informed client.

  • Show your documented processes Give clear timelines

Processes show you are internally organized, however, when sharing your timeline, you will show you are in control by managing deadlines, dependencies, lead times and milestones. Most clients don’t mind waiting what you might think is a long time, but only if they understand why. Timelines allow a client to understand time-related metrics, set deadlines, synchronize tasks, identify risks, and plan mitigation for potential delays. These diagrams are useful for managers who want to get a high-level look at team tasks and milestones of the project.

  • Cover more solutions Prioritize

You could work overtime and cover 100 different features in just one sprint but if those tickets are not high-priority to your client, they won’t be happy at all. In fact, they may complain about the way you are organizing your work without consulting them. 

Make sure your effort is worthy. Review your priorities along with your client and have them decide the order in which you should be boarding those items. Of course, you don’t want to forget calling out tech dependencies if applicable.

  • Be optimistic Be realistic

Don’t underestimate tasks and don’t play the hero by taking more than you can achieve in a determined time,  set the right expectation up front. It’s better to commit to less and deliver more.  Your client will appreciate the extra effort (remember priorities). 

  • Be an open book Be honest 

Clients don’t want problems, they want solutions, that’s why they hired you in the first place. They can understand errors can happen, but they’ll want root cause and time resolution. You’ll want to explain clearly and honestly the root cause (triggers, dependencies, if it is related to bad code or not, etc) But, most important they want to know which are the next steps and the action items you are taking to ensure the error won’t happen again. And of course, they’ll ask how much time you’ll need to solve it, you will need to provide realistic ETAs.

  • Deliver solution quickly Update regularly

ETA sounds like a bad word, but is necessary. We all know you are focused on solving the problem, but the client wants needs information. Take into account they might need to update their own clients or executives. If you don’t have an ETA and cannot provide it at all, agree with your client in a way to communicate (media and frequency) and make sure you share a status on a regular basis. If the tasks are taking you longer than expected, share the update and explain the reasons.

In conclusion, present your timeline, make sure you comply with it, report delays in a timely manner making sure you provide root cause, justification, new delivery dates, and update your status on a regular basis.

 

How many times have you worked with development teams where you had sleepless nights since they...

How many times have you worked with development teams where you had sleepless nights since they were half way around the world? Or, wondered if they were working or not since you should be sleeping? Are they working with multiple clients or dedicated to me? This is more than you need to worry about when working on a mission critical product or trying to change the world.

There are many opportunities for software teams near and far with different levels of skill, cost, language, etc. Working with an offshore team (India, Eastern Europe, Asia) you are definitely going to be plagued with time zone challenges. You’ll be up at various hours of the night, and likely find pricing all over the board. They will tell you everything they can to win the business and make you feel comfortable. I am sure there are some good ones out there, but chances are once you start working with the offshore team, you will wish that you went elsewhere.

So, what do you do? Focus on working with a nearshore team. What is nearshore? It is defined as “relating to the transfer of a business operation to a nearby country.” Typically, in the case of the United States, this will refer to the transfer of a business operation to Canada, Central American and South American companies. Once you cross over the left and right oceans, it moves into offshore territory regardless of how it is spun.

The value in having a dedicated nearshore team

With a nearshore team, there are at least SEVEN VALUE POINTS.

  1. Proximity
  2. Timezone
  3. Language
  4. Culture
  5. Cost
  6. Skill
  7. Velocity

As an executive leading teams at a corporate, or a startup founder, I would imagine that these seven value points are extremely important for you. As part of your development strategy, these are the keys to your success with the right nearshore partner. You should not only expect but demand these things from the partner.

In the business landscape, competition is coming and biting at your heels so you only have the time and bandwidth to get this done right the first time. I’ve heard time and time again, “well, they cost less than a US team so if there are problems and we need to redo it, it will still cost less than a US-based team.” I cringe when I hear this as it is really an unacceptable approach, especially if you select the right partner the first time around. What they did not calculate in this approach is the cost of “time” in addition to the budget burn. So, in the end it really cost 2X the time and budget in addition to the opportunity cost of other things that could not have been done in parallel.

In a recent CNBC article, “Twitter CEO Jack Dorsey’s comments about San Francisco are a warning sign for the city’s tech scene,” Jack was quoted as saying “I do think that we need to figure out how to build a company that is distributed, that is not burdened by time zones, but is advantaged by them.” Based on his company’s needs, nearshoring is an opportunity that will bring them advantages. This is a huge statement.

Internal, external or mixed teams?

Do you need a traditional in-house team? A 100% remote team? Or mixed? These are important questions to help ensure that you are setup for success, today and tomorrow.

There is no one answer here, but rather depends on your specific needs and requirements. Here are a range of questions to ask which should help you arrive at an answer that works for your situation.

How can I maximize the output by extending the budget as far as possible?

Do I have business critical dates/milestones that I am trying to meet?

Do I need access to specific skills that I can’t find locally?

Am I not finding talent fast enough?

Do I have enough office space based on the budget allocated? Or, can I transfer some of that office budget to expanding my team?

In the world of working remote, and all the available tools, is there a business benefit to having the team in-house at the same time?

Do I value a good night’s sleep so that I can focus on my mission?

Is extending company culture across teams important to the success of the business?

Do I want the team productive or moving in and out of meetings which could reduce velocity?

Would your business benefit from long-term retention?

And the list of questions can keep going and going. I think you get the idea and hopefully the examples here help you to formulate those questions that are important for you.

Keep in mind that the intended end result is an “empowered team that can tackle challenges and provide results” that help you to move things forward. So, either a combination of in-house and nearshore, or fully nearshore, could likely be the best arrangement as a result of the answers above.

Hiring fully in-house, you expect many meetings, a lot of management, budget burn, and one on one time to align with product or company objectives. Balancing that with a nearshore team, the rules of the typical office space don’t apply and the budget is extended. Typically you communicate more and intrinsically give your team more freedom to make decisions while providing overall product direction. This really helps to drive velocity which is hugely important in the competitive landscape.

Just like an in-house team, a nearshore team is dedicated 100% to you, and if setup the right way can absorb your company’s culture and goals. On the other hand, offshore teams will take more of your precious time and effort to bring them into alignment.

If you find the right nearshore partner, that will take inventory of your needs and help you to scale swiftly with the right skill and talent. To help ensure this, transparently, you should be invited into the candidate selection process since this person will be a fully dedicated member of your team. The last thing you want is just to have butts thrown into seats to see if they fit or not. Not a good situation, and believe me, if this is offered to you…..run the other way. On the same token, if a vendor says “trust me,” well don’t unless they are providing some sort of (put your money where your mouth is) guarantee.

Nearshore teams could provide the best all worlds, but again really depends on your business goals, needs and requirements.
Lastly, here is a list of potential benefits working with a nearshore team should you find the right partner.

Benefits you get with a nearshore team

  • Collaboration: You have full visibility throughout the candidate selection process and collaborate with our recruitment team to interview and secure the best talent and skill.
  • Allocation: Your hand selected team is 100% fully dedicated to you.
  • Managed operation: Operational support and facilities for your team to do their best work.
  • Working Hours: Your nearshore team should work within your timezone. For example, for all of our US based customers, teams work within the EST (GMT-5) to PST (GMT-8) time zones to ensure overlap with their work day.
  • Proximity: Location is important. Your team should be easy to get to in a few hours. For example, the Ideaware office is only a 2 hour flight from Miami, or 5 from Dallas.
  • Transparent costs: Flat monthly rates and no hourly or hidden fees.
  • Cost savings: Potential savings of up to 60% of the costs from hiring a US-based team.
  • Culture: We encourage our partners to embrace the software design and engineering teams as their own. These teams will feel like a seamless extension of your company.

The right partner will help you understand the benefits and challenges of working with a nearshore team and advise what’s best depending on your specific situation. The team at Ideaware is always available to help you succeed by supporting you with best in class team augmentation services for software design and developers.

If you’d like to learn more on what makes a software team successful check out or post: 5 Secrets behind a succesful software team.

So, you are done building your app and deployed it to production, but you have no idea if people are...

So, you are done building your app and deployed it to production, but you have no idea if people are actually using it or how are they interacting with it. What features do most people use? What are, if any, the chokepoints in your app? Is your app even up right now? You just checked, didn’t you? What about in 3hrs when you are at dinner? Luckily your app can answer these things for you with the proper tools.

For starters, why SHOULD you monitor your app? Well, one simple reason: Users aren’t patient. If you have a really slow app or it just isn’t working then people will leave. Users who leave are users who aren’t paying. You are literally losing revenue by not monitoring and seeing that your app is in top condition: Users will stay in your app if they don’t have to pull their hair out to use it.

Performance

Monitoring an app involves knowing how well it is performing. There are various metrics that can be used to judge the overall performance of your Backend such as throughput of endpoints (how many requests to that endpoint come through a period of time), time consumption of each request and DB usage.

By rule of thumb, it is easier to order your endpoints by highest throughput and work your way down seeing how well they behave and watch out if there is anything you can optimize. If you target the most used endpoints first you will be having a higher impact on your user base and any subsequent improvement will have a higher repercussion. Once you start associating the highest throughput endpoints to features, you can have a very good picture of what the average user is interacting with inside your app.

After you’ve gone through the most used endpoints, it’s time to tackle the slowest overall. Even though these MIGHT not be used that much, on average they are very slow so any request will be on the slow side of your site and frustrate any user who is unfortunate enough to have to use it. It’s very likely that the slowest ones might also have the highest DB usage so try and check them out for the usual suspects of n+1 queries or missing indexes.

It’s important after you have optimized your backends endpoints as much as you can to continue monitoring them monthly seeing how they behave. Correlate how much your user base growth is affecting the overall performance on each one of your endpoints. Everything might work fine and dandy with ten users but at a hundred, thousand, ten thousand users its likely to start seeing some degradations in performance. This will give you a better heads up if in the long run it would be better to adapt your current solution to something else.

Error Tracking

You finally have your super speedy app and everything is done at the speed of light, but it would suck if most of that are just errors and buggy interactions. Most users won’t report errors but rather just close the tab and move on to find something else. That’s why it’s also important to have an error tracking tool, something that alerts you to errors your app is having in production. Fortunately, many tools exist such as Sentry or Rollbar which track errors across your applications stack.

It’s important to address errors as quickly as possible to avoid further complications on your users. Most of the tools used for error tracking provide extra context and information so it’s easier to reproduce the error in your local environment and debug it.

Availability

The other side of monitoring involves knowing if your application is up and running smoothly. Since most applications use a variety of services to function its ideal to have multiple alarms checking various metrics to correctly determine if something is down or not running as expected, some examples are:

  • A periodic simple ping to your Backend/Frontend service might also be a very useful method of determining if your application is available.
  • If you have a stable throughput of requests, a significantly lower number can be a clear warning sign that something is wrong and some actions need to be taken.
  • Establishing a borderline Database CPU usage, in case the issue at hand might belong to the Database.

These are just a few guidelines that can be used to make sure your web app is in top condition and running smoothly. It’ll save you lots of headaches to know how well it’s performing so you can act quickly and decisively when making architecture/software scaling decisions. Establishing certain metrics to act as alarms when something is amiss is also crucial for maintaining a high availability.

I've worked with dozens of technical and non-technical founders over the last few years. Technical founders...

I’ve worked with dozens of technical and non-technical founders over the last few years. Technical founders typically handle the software side of the business well (team, tech stack, etc) while non-technical founders struggle to materialize their vision.

Business experience and vision are important, but also making sure you have the right stack, the right people for the job and a solid execution plan.

It all boils down to filling in the technical gap. By doing so, non-technical founders maximize their chances of releasing good software that sells.

Here’s the top advice I give to non-technical founders that will help set them up for success:

You need someone technical on your side

A business needs to run, software needs to be sold, a vision needs to be executed. This is where non-technical founders should spend their time. Not learning to code.

Find someone to fill the gap, in any of these forms:

  • Bring on board a technical co-founder
  • Hire a Lead/CTO role right off the bat
  • Partnering with a firm who provides the talent, including lead technical roles

Having a technical parter frees up your time so you can focus on the business, while at the same time you have someone you can trust taking care of the technicalities.

Share your company vision

Sharing your product & company vision both empowers and motivates your team. We like to feel part of something bigger, specially when working towards a common goal.

Sharing your vision also helps your team make better, decentralized decisions that align with the company objectives. Teams working on random small tasks in a black box are typically not motivated. This is why sharing your vision is important.

Sharing your vision leads to a motivated team which leads to a great product.

Be there for your team, lead

Teams are not for “setting and forgetting”. Your team can’t work in a black box and produce your expected results.

Remember you are working with human beings that need to be listened and taken care of. Lead your team by setting an example of work ethic, leadership and most important of all, stand by them.

Whenever someone needs help, help. Whenever you need help, ask for it. People like to feel helpful.

Don’t compromise, expect results & quality all the time

Quality, deliverables & results are expected and non-negotiable. Period.

Expect the highest standards from your team and hold everyone accountable. Create a culture where your own team sets the bar that everyone meets everyday.

If someone is underperforming, offer help. If it’s a mayor or recurring issue, consider finding someone who is a better fit for your team.

Mistakes happen, but they should not be the norm.

Hope you enjoyed and got something useful out of this article. Feel free to share!

Serverless seems to be the hype word for applications right now. Every cloud platform from AWS to Azure...

Serverless seems to be the hype word for applications right now. Every cloud platform from AWS to Azure to IBM is listing serverless services and spreading its pros everywhere. However, before we get into serverless applications we need to understand: What is being serverless about? Are we truly going around without servers at all?

The serverless computing model offers to focus on the business side instead of the infrastructure. The majority of platforms offer serverless architectures that are cheap and easy to maintain. Serverless architectures are often based on Functions as a Service (FaaS), deploying only a piece of business logic in the form of a function. Some examples of these functions are AWS Lambda or Google Cloud Functions. Implementing the serverless model is very attractive because it means less time getting lost on the implementation of complex architecture. But there’s more to this than meets the eye.

First of all, serverless does not mean getting rid of servers. It just means that the cloud vendor will manage the allocation and provisioning of servers in a dynamic way, so your application can run on stateless computers triggered by an event. Every time a function is called, the cloud vendor manages to assign a compute container for that specific execution. By doing this, the vendor prices the services based on the number of executions rather than computing capacity.

Until now, going serverless should seem easy as a piece of cake, but not everything about the infrastructure should be left to the cloud vendor. For that reason, here are 5 tips for building a serverless application smoothly:

1. Be aware of the use case:

With the advent of serverless, long gone are those days where we had to spend a lot of time and resources every time we wanted to launch to production. On serverless, we don’t have to worry about load balancing and orchestration anymore because it is outsourced now. However, the serverless computing model doesn’t work for every use case. For example, taking into account that on AWS Lambda every function should get executed on a window of maximal 15 minutes, we know beforehand that long-running jobs won’t work in serverless.

Also, if you can’t predict how much resources like disk space and memory your application is going to use, serverless services won’t be the best approach since they have limitations on that per their nature.

2. Use IaaC as much as possible

In the serverless computing model, there is no server administration as we know it, but it doesn’t mean that it is completely no-ops. There is indeed a need to set up and deploy a serverless function, allocate resources, time out, environment variables, etc. Doing that is kind of tedious, and more for developers not used to managing infrastructure. Don’t worry, though, Infrastructure as Code (IaaC) is the solution for that.

Terraform, Ansible, Cloudformation and others are around to help you convert infrastructure issues into code that you can copy, paste, test and even share. Defining every one of them would be a matter of another post, but you can always rely on their wonderful documentation. Last but not least, there are also agnostic frameworks to deploy serverless code on several cloud platforms, like Serverless (Javascript, Python, Golang), Apex and Up.

3. Keep your bundle as small as possible

Even though serverless cloud platforms support a lot of languages and frameworks, we should keep in mind that anything resource-hungry doesn’t work on serverless. For that reason, the advice is to keep everything as small as possible, since serverless applications are meant to be lightweight.

For the use of dependencies, it depends on the used language and its version whether it’s a challenge or not to implement them. In the case of Javascript and NodeJS, they bring a lot of native dependencies making this easier, but that’s not the case for C, to give an example.

Just remember that serverless functions are limited on disk space and memory, because of that the fewer dependencies a function has, the better performance it has on this model.

4. Keep in mind that serverless functions don’t have IPs

Since serverless functions are servers allocated dynamically, they don’t have IPs. That’s important to remember whenever you are accessing third party APIs through VPNs. If you need to access a private endpoint and the only authorization possible is through whitelisted IPs there are ways to work around this on serverless applications.

At least on AWS Lambda, you can put the functions inside a security group inside a VPN, which is connected to an Elastic IP in order for them to have a static IP.

5. Don’t forget Serverless also means stateless

Last but not least, you cannot forget that serverless functions are stateless, even though they might store a certain cache. Two executions of the same function can run on two different computing containers, for that reason you can’t just store data on disk space.
If storing data gets necessary, you can always rely on external services such as databases or file storage services, such as S3 and DynamoDB on AWS.

Recruiting software development talent is a particularly challenging art, but done in the right way, it becomes very...

Recruiting software development talent is a particularly challenging art, but done in the right way, it becomes very rewarding.

We understand that finding the right talent for your project is time-consuming and demanding. At Ideaware we make sure you don’t have to worry about that. Hiring an outsource/nearshore software team is meant to be easy and headache-free.


“In technology, it’s about the people. Getting the best people, retaining them, nurturing a creative environment, and helping to find a way to innovate.”  -Marissa Mayer

From profiling to hiring

We want to make your vision a reality. To make this happen, we’ve crafted a repeatable process, with an extraordinary technical team to find the talent to meet your needs for “skill and scale.”

Stage 1: Preparation

Let’s get started!

Whether you are scaling your team or hiring a dedicated team, the first step is to identify the requirements of the position you need for your project. After the vacancy request is made, our Human Resources team will begin to work its magic. 

We use a collaborative recruiting method, which means that with our tech leads, we create the right job profile of required competencies and skills based on your needs. From this moment, we use our recruitment techniques to spread the message and the head-hunting starts.

Stage 2: Prescreening

This phase consists of selecting, organizing, and identifying cream-of-the-crop candidates by reviewing the applications. When we have selected the profiles that meet the requirements, the screening process starts with a call to each applicant. 

Here comes the fun….

Stage 3: Technical Interview

After the screening process is done, our HR team and tech leads schedule an interview with the very best candidates. We conduct a series of questions, challenges and evaluate their creativity, ability to problem solve, and culture compatibility. In the end, our tech leads give us the evaluation form with a score and feedback.

Stage 4: Job simulation exercises and final interview

Here is when you come to the mix! We share with you between 2-4 top-talent candidates with their job profiles and technical results. You review and select the ones you believe are the best fit for your project, and we will schedule your interview with them.

During this final interview, we conduct a work simulation challenge. This will help us to check the candidate’s expertise, qualifications, and understand how they will react in a future work situation. 

Stage 5: Offer and hiring

After you select your A+ candidate and give us the green light, we make an offer and our HR department starts with the hiring process. We take care of the rest.

You are all set!

Nothing but benefits…

These are just a few reasons why you should hand-off this process to us:

  • You don’t have to worry about contracts anymore.
  • You will have more time to focus on your project while we focus on finding the right talent.
  • Our experts will put together a team that goes with the personality of your project, culture, and fit your expectations.
  • The days when you had to spend endless hours screening candidates are over. Now you can spend this worry-free time centering your attention on your goals.
  • You will just interview and screen candidates that are already aligned with your requirements.

“Hiring talent is a multi-faceted skill that lies at the crossroads of social networking, technical acumen, process management, and intuition.”  -Hyam Singer

Remember that hiring is a journey and we are here to help you along the way to build the right dedicated or extended development team exactly to your needs.

Thanks for reading, hope you liked this post. Please feel free to share and don’t forget to subscribe to our newsletter below!

We invest a lot of time at our jobs. Now that we’ve shifted to working from home, we must interact more with our...

Who wouldn’t want to work in a place where they feel happy, safe, and valued?

We invest a lot of time at our jobs. Now that we’ve shifted to working from home, we must interact more with our coworkers to keep things moving and our minds sane. Being happy and having a healthy work environment is vital not only for our mental health but also for our productivity. Unlike what most people might think, creating a good work environment is not only the sole responsibility of supervisors and/or senior management teams. It is the responsibility of everyone involved in an organization. 

But how can we contribute to having a happy and healthy work environment in such hectic times, when we have deadlines to meet, goals to be achieved, and still, balance all of that with our personal lives and responsibilities? Well, you might be surprised, because it’s not as hard as you might think, and it depends a lot on ourselves as well. 

These 7 tips are fundamental  to create an environment that will, for sure, make you want to wake up every day to go to work:

  1. Respect everyone: Treat others as you would like to be treated. We have heard these words so many times before; but are we living up to them? Having due regard for other people’s rights, feelings or wishes is the root of peace.
  2. Effective communication: Have you ever stopped to think about how many misunderstandings and problems could have been avoided in life if you had communicated properly? The same thing happens at work. Communication is much more than just transmitting information from one person to another. It needs to be accurate, effective, and clear. Effective communication will build trust, will provide clarity and direction, and most important of all, will create better relationships between coworkers and supervisors.
  3. Take breaks during your workday: Long hours in front of the computer is anything but healthy and does not translate into productivity or faster achievement of goals. Try to make a pause to stretch your body and muscles at least twice a day for ten minutes each. You will soon start to feel the benefits this brings, not just to your body, but also, to your ability to concentrate at work.
  4. Avoid gossip: Avoid negative conversations, gossip, and unhappy people. Live your own experience, and if you find yourself in a difficult situation, use the appropriate channels of communication established to try to come to a solution. Remember that communication is key to a happy and healthy work environment.
  5. Be kind: Kind is the new cool. We don’t always know what people who work with us are going through. Take your time to get to know them. Try to make at least one person smile at work every day. You will see how this simple act will change not only the other person’s day but your day as well. Good acts cost nothing and make a huge difference.
  6. Help each other out: Be that person you would like to have by your side when you’re in trouble. Organizations are all about teamwork and building experiences together. Your coworker’s failure will never be your success or the success of the company. One for all, all for one.
  7. Love what you do: Last but not least, you need to love what you do. Waking up every day to do something that you’re passionate about will keep you motivated and happy. Your levels of performance will be much higher and your creativity will start to flow. Sooner rather than later, you will realize that goals are much easier to achieve once you have the drive to reach them.

At Ideaware, having fun is one of our corporate values. We are all about balancing responsibility and well-being. We understand that keeping a happy and healthy work environment is everyone’s job, and we work hard to make that one of our goals every single day. It brings great benefits for both employees and organizations, and a lot depends on you. Think happy, be happy. 

‘What you think you become’ -Buddha.

Thanks for reading, hope you liked this article. Please feel free to share and don’t forget to subscribe to our newsletter below!

We’ve all been there. Talking to a friend when suddenly you get that “Aha!” moment of a brand new idea for ...

We’ve all been there. Talking to a friend when suddenly you get that “Aha!” moment of a brand new idea for the next big mobile app. The current state of technology allows many people to dream big and start building software to solve a problem they’ve experienced or seen first hand.

However, this is no easy feat and if you want to jump on the boat of creating a web product, you’d better prepare yourself with some readings that will open your mind to a new world of opportunities.

Keep on reading to find out which books you should be buying next.

A Good Comparison First

A good analogy for building software is building a house. You plan, assign a budget, get advised, hire ideal people, and off you go.

On the other hand, building software is more flexible than a house.

Once you have the foundations and walls of your new house, changing the base structure will be very expensive and time-consuming.

Software is more malleable.

You won’t be able to modify base structure every time but there are techniques to handle the constant evolution that software projects face.

The most important thing about software being malleable is that you have to embrace projects with a very different mindset where constant change is a must and nothing is ever taken for granted.

You also have to consider a new way to handle things. To consider software as a new universe where things happen differently.

The following books are all about this mindset.

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

Website

What I found best about this book is the approach it proposes. Sprint was written by Google Ventures members. The authors are people that have the money and power to hire people, pay for services, but that’s not the approach they want you to take.

Spending money is expensive, so Sprint wants you to do something better: validate your idea as many times and as fast as you can.

The book wants you to experiment.

Your awesome idea is awesome but you’ll face harsh reality once you take it to people to dissect it and give you down to earth feedback. First, validate your idea in a small experiment with the target group, collect feedback, iterate. By following this path your road to success will have a rock-solid foundation without guessing what your customers really need or want.

The words you want to learn and practice a lot are: experiment, prototype, validate, feedback loop, iteration.

In the end, you want to build a software product or service and, trust us, we’ve been doing it a handful of years, it’s not an easy two months thing.

Of course, you can throw everything away, do what you believe is best and create that incredible software without help from outsiders but as soon as you get it to the real world, you’ll see everything you missed and will probably find yourself thinking “if only I had asked…”

Getting Real: The smarter, faster, easier way to build a successful web application

Read online

This book is kind of a “bible” to me whenever I start a pet project.

Sadly, I read it for the first time too late after building failed projects at the personal level and company level.

This was the year the Lean methodology was booming and I got the chance to participate in a country-wide effort to get more people to build software. In this government initiative, several workshops were available to participants. In one of those workshops, here in Barranquilla, I learned about the MVP: Minimum Viable Product.

The instructor explained the MVP is the smallest version of your application that fulfills the customer needs. It was a mind-opening moment for me because I knew why I had failed before when doing my own software projects.

I tried to get those ideas to my boss at that time but with no help. The guy was stubborn and unfortunately, money was spent and lost. Project closed.

I can’t really recall how I found the book but reading it was such a good experience. It mentioned everything that went awry in that project, how we could’ve put it back on track, how to handle third party requests.

Third-party requests can kill a project.

We were working on a Learning Management System project for schools. Every time we leave a school after a meeting with the manager, a pile of requests would accumulate in our infinite backlog.

Several shortcuts and spaghetti code was written to handle so many specifics between schools. When we realized we couldn’t give everything to everyone, it was too late.

Getting Real is a book that will give actionable advice on how to avoid and not to fall into those traps.

When you’re starting your web software, you don’t need to wait a whole year to try it. You can plan small iterations and start testing with your friends, family, pals, people on the streets. Don’t fall into the trap of waiting for it to be “ready”with everything because it’ll be too late. Besides, in six months, you’ll have new ideas and the deadline will be moved or mismanaged because there’s a lot more to do.

Don’t do that. Go with the small iterations approach. Remember, Google Ventures employees advise it.

Also, a very good advice from Getting Real is “Less Mass”. Don’t get attached to “a hundred features”. That’s a sure way to fail.

Did Google start with Gmail, Hangouts, Drive, Cloud, Docs, Keep, Calendar, etc, etc? No, they didn’t. Google started as a search engine and grew from that.

Yeah, it’s nice to have a million features but it’s not worth it when you’re just starting. You’ll be losing a lot of time and money chasing the perfect app instead of delivering (and even better, charging users) early and often.

Shape Up: Stop Running in Circles and Ship Work that Matters

Read online

This is an awesome book. It explains how Basecamp (writers of previous and this book) work and the way they organize work to be done in a given period.

If you want to take advantage of the lessons in Shape Up, you need to prepare your mindset. If you’re new to software projects, it can play in your favor as you’re not so biased with other project styles such as scrum, kanban, waterfall, etc.

In summary, Shape Up wants you to do a great job defining what’s going to be done in the next six weeks. Leave all uncertainty behind, so that developers can go for it with less amount of doubts or unclear requirements.

By defining an overarching goal, you’ll let developers and designers figure how to reach it by themselves. No need to create story cards, tasks, subtasks. Just one goal. Let devs create their own tasks if they feel they need them or whatever methodology suits them best.

Normally, in a software project, there’s always something great that will pop up in the middle of an iteration. This is usually a “great” idea by someone in charge and all of a sudden they give it top priority because without it the product “would be useless”. That’s complete BS.

It’s not bad to have ideas. What is bad is to let them slip through your process. Shape Up (and also Getting Real) tells you to say “no” to that idea, at first. Reject the idea until several people or users are affected by the lack of it or even better, they suggest it.

Shape Up proposes a six weeks cycle because it’s a good amount of time to deliver something meaningful. Of course, this is not set in stone and you can test and find the best cycle for your team. What’s important is giving proper time to do serious research, validations, small iterations, and being able to deliver great and important work.

It’s not going to be six weeks doing “small things”. By no means, those six weeks will be spent doing the important work, delivering value to users. This usually means big tasks. Big releases.

Building software is an exciting journey. There are exciting, complicated problems to be solved, and a new way to help companies or people with their daily lives or routines. Software is very important in our daily lives and this is why building software requires better processes, better mindsets, and better ways to create them.

When building great software, the path and the destination must be great as well. Fortunately, there are awesome books to learn from experts and set yourself up for success.

Thanks for reading, hope you liked this article. Please feel free to share and don’t forget to subscribe to our newsletter below!

Let’s chat, we’re user friendly!

Thinking about starting a team? Need to augment your existing team?
We’re here to help. We work with US based companies to help them grow!

You’ll be talking with
Max, our CEO.

The team list

Building a team? We got you. Get the best tips and how-to´s weekly on your inbox.

Contact
Contact

© 2021 Ideaware Co. With ❤️ from Barranquilla, Colombia.