It goes without saying that software is the future. Apart from improving businesses and their processes, these new technologies are also used to create new services and products. At Scio, we help our clients as they look to utilize the software for their companies. Founded in 2003, our vision is to help others achieve their business objectives by leveraging digital technologies. Our dedication to developing software has recently resulted in a The Manifest award.
First and foremost, The Manifest is a business blog website that aims to gather and verify the hard data, expert insights, and actionable advice that you need to build your brand and grow your business – to provide the practical business wisdom that manifests in your success.
To be featured as a most reviewed company in a competitive industry like software development is a huge milestone for us. This award is proof of our incredible ability to deliver incredible solutions and products to our clients. It is also a testament to our team’s hard work and passion for providing the best services to our clients.
Speaking of clients, this award wouldn’t have been possible without their support. Thank you for trusting us with your business and for always believing in our ability to deliver amazing software solutions for you. Again, we would like to extend our gratitude to each and every one of you for trusting us with your business.
Are you looking to build or expand your software development team? Tell us how we can help by dropping us a line today.
Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies to help you reach new heights. We have been developing since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – we’ll be happy to help you achieve your business goals.
How to measure productivity effectively? Adolfo Cruz, Scio’s very own Project Management Office director, offers insights into a question many in the business have in their minds all the time.
By Adolfo Cruz.
Building an exact image of productivity is a question with no definitive answer yet. Defining what “productivity” means for someone starting a business for the first time is a complex process. From everything I’ve learned these 14 years at Scio, each person needs to discover what works for them, considering the specific context in which they are trying to succeed.
The thing is, when trying to measure productivity in something as fluid as software development, every seemingly useful metric comes from a different perspective (be it from the client, the developer, or the managers), so if you want to establish a baseline, I would recommend defining priorities first, taking into account your business needs.
How do we measure productivity in Scio?
Early in Scio’s history, around 2008 or so, we tried to implement Agile Methodologies along with some number crunching, like the hours put on a project or the number of bugs, to know exactly how productive our teams were. However, the number of variables involved, like realizing that a specific team had better outcomes because they had certain chemistry between them, made it difficult to translate the results into measures that could be implemented in any project.
So we moved away from that, instead of looking at the results from the client’s perspective, thus defining our productivity as the value our developers are adding to a product during development. Our measures became more focused on people than metrics because helping a client to build a product, adding value at every step, and therefore growing their business, was our main priority.
To this end, building a perfectly calibrated development team that proposes new things, learning and evolving together was the best approach for Scio. A lot of the time it’s not even necessary to keep a register of everything happening during development because the team itself realizes when something’s not right and works out any issue; a team of developers capable of self-management is always a good sign.
If you achieve such a team, you don’t need to measure specific metrics for each collaborator, instead, you evaluate the team as a whole, looking for relevant information that can help them grow, so you should think of questions that help you get the information you need.
For example number, many User Stories were completed in a given time?
Was there any serious bug in the development of the product?
How many bugs surfaced?
What priority did these bugs have?
How did the team respond to them?
How long did it take?
However, these questions need to be constructed with the project’s context in mind; although there are a lot of metrics you can use to generate specific “productivity” numbers (like the Personal Software Process popular in the 90s that tried to define productivity through the number of lines of code written), if they don’t reflect reality, then the team will not know how to use this information, as many of the challenges they face can be subjective.
So avoid trying to arrive at exact numbers, and instead, I recommend you to look at the trends emerging from one project to another. A trend interpreted correctly should give you a “big picture” of both performance and productivity, showing places where your attention or some improvement is needed.
First, look for a certain range of information in a development cycle; If the team completed between 5 and 10 stories in a sprint, but only 1 or 2 the next one, there’s probably a red flag somewhere in need of attention. Then dig a little into it, and maybe you’ll find some unforeseen challenges the team needed to prioritize to keep making progress. And finally, make a note out of it, so you can improve the circumstances around an issue so it doesn’t reappear later; that’s how an understanding of productivity begins to emerge.
Most of the trends we watch at Scio are about how our developers contribute to our client’s goals, and we developed some tools to measure that. For example, we use the Team Self-Assessment, a guideline for collaborators to reflect on their work, that we adopted and modified according to what our experiences and specific contexts dictate.
In our TSA, there’s a section where we inquire about bugs surfacing during development, asking how they are preventing issues during development, if they are doing Pair Testing practices, if they are showing their additions to someone else before moving on, and generally if they are focusing on things that matter.
When a team reviews these questions, they realize their areas of improvement, and we work together to avoid falling into them again in future projects, because what you want to do is push your teams into adopting excellence as a natural part of their processes, encouraging them to add their experiences and expertise to the final product.
The subjectivity of a productive team
Productivity is not always a purely technical approach; sometimes you need to look at the business side of things, involving the stakeholders and product owners in the creation of the product to reconcile a multitude of perspectives, converting them into priorities to define the best course of action.
Just remember that you need to experiment in software development, build an iteration of the product to validate its potential, and look for features that can be improved to maximize its success. Your development team will probably need to go back and rework a lot of stuff, updating their methods to create a more efficient version of the product, so your definition of productivity here has to account for it; if stuff is being redone, at least quality should always be improving.
So, to recap, a good measure of productivity is established by defining your business priorities and then choosing the metrics that best reflect the context in which the product will be built. A productive development process gives enough flexibility to iterate and experiment without neglecting business needs, and having your client’s goal as the focus of your team is a great starting point.
Just remember that if you aren’t adapting what you learn into your specific context, capturing the information your team needs, then productivity might suffer. Software is mostly a creative enterprise, so some subjectivity will always be needed to properly define what makes a successful project, fine-tuning every cycle to achieve the value you want for a specific product. With an approach like that, you can be sure your organization will always be improving.
How to measure productivity? That’s a question that many in the business, from CEOs to coders to engineers to managers, have in their minds all the time, and Adolfo Cruz, Scio’s very own Project Management Office director discusses metrics, measures, and meanings of productivity.
At the end of the 90s, a methodology called “Personal Software Process”, or PSP, was designed to help developers measure their productivity. You had to take a course, there was a lot of documentation to follow through, and you had to use a timer to measure your progress, stopping it every time you needed a cup of coffee or to go to the bathroom.
The idea was to see how much you accomplished in a day, but in fact, this methodology was entangled too closely with the number of lines you wrote, meaning that you were more productive the more you coded, which is not necessarily true.
But if this is not productivity, what is it?
I define “productivity” as finishing a task in a reasonable time. The word “finishing” here is key because productivity is not starting a lot of things, but seeing a project to completion, right until you get a product. However, how do you define exactly when something is “finished” in software development? What criteria do you have to fulfill to say something is done? If we were building something physical, let’s say a boat, first, you need to build a hull, and this phase ends when it fulfills certain requirements.
And although not all boats are the same (building a freighter or a yacht would look very different), in essence, you have the same process, blueprints, and requirements to do it. Software development doesn’t work that way.
Developing software involves a lot of things. You may see it conceptualized as a “factory”, or a development team working like a well-oiled machine, where you input requirements and get a product at the other end. But in truth, there’s an artisanal quality to developing software; everyone has their approach and style, and progress changes according to the team you are with.
This results in a lively debate where no one agrees on the best way to measure productivity. If you ask a room full of developers how many lines of code they write to see if they are productive, you can get a very heated discussion, because how are you measuring that?
The best code is concise and everyone checking it can understand it, so I don’t know how you can see someone writing 10,000 lines of code and conclude he is more productive than someone achieving the same in 500. Maybe it made more sense at a time with no frameworks to build things faster, when everything was a bit more rudimentary and you coded every single piece of the product, but today you have to write very few things from scratch, with a whole range of tools that let you produce, let’s say, the shell of a website in a minute without coding anything directly.
So imagine if a company starts giving productivity bonuses based on lines of code produced per project. They would end up with developers gaming the system to get the bonus or at least trying to not look worse than their peers by writing less, resulting in bloated, inefficient products because the incentive wasn’t centered on creating something useful.
You have to be very careful when linking rewards to metrics, or else you’ll generate a perverse environment where everybody is just racing to inflate numbers.
The Scio way
I’ve been with Scio for 14 years, and since then, perspectives have changed. With the arrival of Agile Methodologies, we moved on from counting lines of code to seeing how that code comes together, achieving working software whose process of development is not focused on numbers, but on how the product is going to be used.
To give you an idea of this evolution, not long ago the requirements of a project were written from the point of view of the system, so every requirement started with the phrase “The system shall…”: the system shall do X thing, the system shall do Y thing, the system shall do Z thing, etc.
So you ended up with a massive document repeating “The system shall…” for every little thing. Then the Agile Movement centered on the user, with requirements stating “The Administrator can…” or “The Manager can…” because we understood that software is not about a system that “shall” do things, but what people in different roles “can” achieve with the product, resulting in productivity built around how much value we give to the final user, not how much code our devs write.
Coming back to Scio, we see it from the perspective of the stakeholders and clients we are building a product for, and our productivity is measured on the information we get from them, knowing how our teams are doing, how much value they are adding to a project, and what their perception of the whole process is. It’s a more people-oriented approach, far from the days of counting lines of code, and more interested in understanding how a developer is contributing to the goals of our clients.
To that end, we developed some internal tools, like the Team Self-Assessment, based on our prior experiences, consisting of questionnaires about the things we consider important for a team to focus on. For example, there’s an entire section about quality, how they are preventing issues during development, if they are doing Pair Testing practices, or if they are doing code reviews to make sure the code is maintainable and scalable…
Are they giving issues the proper attention? Are they documenting them? The team members have to ask themselves if they are focusing on the right issues, and if they aren’t, it’s something we have to improve. That’s how we try to motivate our teams to share their experiences, practices, and insights into our client’s projects.
It is said that only 35% of software development projects succeed, and I think it has to do with the planning stage of a product. Let’s say I want to complete the A, B, and C steps of a project in six months, based on previous experiences in similar projects. But it ended up taking 8 months instead of 6 because something needed to change, does that 2-month delay mean the project is going wrong?
It happens a lot with start-ups trying to create something completely new. In the course of development, it’s common to see something, a feature or function of the product that changes the client’s perspective, that taps into some potential we haven’t seen before, so the plan has to get reworked to harness that and bring its full potential. In six months, priorities can change.
But if we measure the productivity of the process very rigidly, and then that very same process brings out the value in unexpected places that, nonetheless, force you to rework entire parts of the project, it’s easy to see it as a failure.
The Project Management Institute uses these rigid measures a lot, asking for a specific basis, beginning, and end of every phase of a project, and if you don’t deliver them exactly as planned, then you get a mark against you. In an actual software development environment, that doesn’t happen, because the dynamics of a development cycle can change fast.
Software development works by evolution
The measures you have to use are subjective more often than not. Some industries require strictness, especially when manufacturing something, but in the world of software, and start-ups in specific, I don’t think it’s necessary to be like this to create a successful product.
This is why we back away a little from the technical aspects of a project and focus instead on the business side of things, having conversations with stakeholders and product owners to get them involved, reconciling all these points of view about what the business needs, and how development is.
We take a look at the features planned, check how many people ask for them, how critical they are for the business model to work, and decide how to proceed from there, adding real value by focusing on building those pieces first. Technical aspects are solved later, as you first see what the business needs, and then the technical team starts sketching solutions for the challenge.
Productivity is a question with no definitive answer yet.
Considering all this, forming an exact image of productivity is a question with no definitive answer yet. Every individual has to decide what works, but only in the specific context in which that person is acting, so no one has come up with a universal method to measure productivity in software development, as even the perspective from which you measure can change; seeing it from a client’s perspective is a world apart from a developer’s.
As you discover better routes during development that weren’t foreseen during the planning stage, or maybe because the technical aspect ended up being unfeasible for one reason or another, or the infrastructure cost is too high for your purposes, or any other number of reasons, a lot of what you may define at the beginning of the project will change.
You adapt, which is very different from building furniture or producing food, where it is clear what you are trying to accomplish over and over. But in software, where there’s no single solution for the same problem, it’s difficult to reach a consensus on what you need to do in detail.
However, you want to measure productivity, metrics evolve, and whatever method you use to decide how productive your team or your company is, I think the Agile Methodologies got it right, where it doesn’t matter the number of lines, or the documentation you have, or how pretty your database is, what matters to the client and the final user is having software that works.
Is technical debt a recurring problem you face, or is trying to future proof the software you write the best course of action? Today, we take a look at one of the most complex problems when creating software, analyzing the pros and cons of both approaches.
by Scio Team
Software development is… complex. At its core, it’s an interesting challenge where improvement and evolution happen alongside the construction of the software itself, with the possibility that it changes course when you learn new things, get a new perspective, or bring diverse points of view to the table.
As we said elsewhere, developing software is very similar to writing a novel, or painting a picture: it’s as much of a discipline as is a creative exercise, borrowing and modifying itself throughout the project. However, there’s a big difference between a book and software; the software is part of an infrastructure, meant to interact with a user, across an undefined period, which gives this profession a unique challenge: what happens to the code I’m writing today when tomorrow arrives?
A debt to ourselves
“It’s OK to borrow against the future, as long as you pay it off”, are the words of Ward Cunningham, one of the authors of the Agile Manifesto, which revolutionized the way we look at software development. We all know how borrowing money works in our daily life, but what he referred to is a specific concept many in the software industry are aware of: Technical Debt.
As you may know, technical debt is “the implied cost of future refactoring or rework to improve the quality of an asset to make it easy to maintain and extend”; is the knowledge that certain parts of a program may require to be fixed at some point in the future.
There are plenty of reasons why a dev team may incur this “debt” (be it for budgeting, skill, or deadline reasons), but the nature of its payment is stumbling onto issues that need to be fixed quickly, which may bring more issues later that will require further fixes and so on, effectively like trying to pay a loan with a high-interest rate. If you are not careful, you will end up paying it perpetually.
Technical Debt is considered a serious problem and plenty of literature and management advice have been written to mitigate its effects, but like with any kind of loan, it can bring plenty of benefits if chosen and managed correctly. After all, if we take on a debt, it is for something in exchange, be it having cash on hand to accomplish something, or achieving working software to solve the issue at hand.
And the proper way to deal with debt, be it technical or otherwise, is to pay it on time, which in software development means refactoring a lot of the work done.
However, depending on the level of debt accrued by a team, this refactoring may bring a hefty tag, especially if the time between creating the program and improving it allowed many dependencies to flourish, or some of the knowledge behind the construction to get lost (such as the original team changing), so you may want to avoid the need of refactoring as much as possible because you don’t know the context in which the program will be improved. So what then?
A proof of thinking ahead
Futureproofing may be the answer. What futureproofing tries to do is “anticipate and minimize the effects of shocks and stresses due to future events.” This practice is not limited to software, but it can help to try and mitigate some of the problems technical debt will bring, especially if we are thinking ahead of the need for refactoring at a certain point in the future or having to deal with legacy software inside critical systems in any organization.
However, saying it is much easier than doing it, and any approach to futureproofing a system, so it can be tinkered with or without issue decades from now, is a tenuous art at best. After all, how can anyone predict what software will look like in 2050? The solutions we implement may make sense today, but will probably need some explanations later.
A solution could be, to create software that follows a pattern, so its logic can be easily deduced by a future dev team, as well as taking the proper due diligence when choosing tools and frameworks that have a better chance to remain supported or at least accessible in the coming years, or avoiding “monoliths” where a single application is responsible for tons of functions, but one can still get blindsided by a development impossible to foresee.
This brings an interesting conundrum for many developers trying to find the right approach: is it better to futureproof software to try and avoid technical debt, or is better to acquire some debt if that means having the flexibility to refactor software at some point in the next few years?
Two sides of the same coin
The reason is very simple, yet has lots of implications: if you acquire technical debt, you cannot futureproof because you are assuming you will need to change things. If you futureproof it, then you are making stuff that will greatly resist refactoring, making it likely to turn into “legacy” software.
A good approach to finding a solution to this is developing products with a few things in mind, mainly no software product is forever, and everything has a shelf life that we will need to wrestle with at some point.
“Generally, it is not until something breaks when a team realizes they have a big debt needing to be paid”, commented Scio’s PMO, Adolfo Cruz, about this issue. “It’s more common when a product is brand new and it’s still building its user base. The volume of transactions is low at first, so you may not see any problems, but if the scalability wasn’t planned well, then it’s more likely that debt will flow under the radar until it’s too late, so it’s important to take steps to prevent this.”
The trick is trying to push back that point as much as possible, having the proper procedures to ensure the code can be fixed. A good commenting discipline, for example, can save a lot of headaches while refactoring an application, letting whoever has to modify it knows what can break and what depends on every function. This can work as futureproofing without going into a lot of technical debt, as many of the problems when trying to refactor old programs is the fact that the code sometimes is not very clear, and in places of a lot of personnel turnover (like a government agency), it’s easy to let cracks grow.
The useful approach, then, is considering both of these concepts as the two sides of the same coin: the delicate balance that is developing good software amidst the needs of the now and the later. A great software development team should strive for products that pass the test of time, while also knowing that nothing is perfect, and using the need for refactoring as a tool, not only a problem.
What do you consider is the best approach when creating software? An application with some debt that will let you fix it in the future if it needs to, or building something hard to repair that may stand the test of time?
There aren’t many professions without a stereotype attached, and programming is sure among them. But are these ideas about the personality of programmers accurate, or are we missing something else? Let’s look into these old myths, and see if they hold up.
By Scio Team
When we think about programming and software, we tend to conjure a specific image in our minds, a stereotype that has accompanied the profession almost since the beginning: the image of a coder hacking away at the keyboard, immersed in a world of their own, without the need of much company.
However, if this was true at some point, it still is? The stereotype of the introverted programmer is an even mix of fact and myth, and here at Scio, where we know perfectly the talent we work with, we want to shed some light on the reality of people applying a special skill to create software.
Is it possible to profile a personality?
Since the days of the classic “Temperament Theory”, which tried to divide people into 4 distinct types (namely: Sanguine, Choleric, Melancholic, and Phlegmatic, which are pretty weird classifications if we are being honest), people had the impulse to try and understand their personalities, where they come from and how they affect their everyday lives.
More scientific approaches to these questions have evolved from the 20th century onwards, and today we understand that personality, affinities, and preferences are more fluid and flexible than we once thought, even if we simplify the whole idea for the sake of practicality.
The Myers-Briggs Type Indicator nowadays is one of the most popular systems to tackle this subject, going more in-depth on the inner workings of a person instead of just focusing on their outward behavior.
Going back to the idea of programmers as introverts, things like the MBTI bring some very interesting insights about this professional field and the people who feel compelled to it. What can we find there?
Let’s define “introversion”
What you need to know right now, is that the “introvert/extrovert” dichotomy is a little outdated, simplifying a vast swath of personality types into two neat boxes with little in-between. What the definition of “introversion” tries to convey under this understanding, is people who don’t have much affinity for a specific kind of social interactions, prefer more individual activities, or with a pretty select group of people.
Although many probably feel this way, reducing it to only these signifiers leaves a lot out. What the Myer-Briggs does is check the balance between the following:
Extraversion (E) versus introversion (I)
Sensing (S) versus intuition (N)
Thinking (T) versus feeling (F)
Judging (J) versus perceiving (P)
What this system maps out is the preference of the person, rather than the ability, so the metrics here assign percentages based on what a person would prefer to do in a given situation, ending up with a combination of 4 letters based on their highest percentages, like INTP or ESTJ. Please take note of the use of the word “extraversion” instead of “extroversion”, which will be important in a minute.
There are pros and cons to this approach, but the important part here is that we have a lot of historical data to see what large swathes of the population prefer, and in programming, the results are pretty interesting overall, challenging many of our notions about the “introvert coder” stereotype.
So… are programmers introverted or not?
We are getting there. First of all, since we are looking into preference instead of abilities, it’s important to note that certain groups, as a whole, will pick one instead of the other; it’s a decision (even if a subconscious one) instead of instinct, or impulse. For programmers, this preference goes towards Thinking (T) instead of Feeling (F), meaning that they like to analyze situations from a more objective point of view, not giving as much consideration to the emotional side of things
Now, this doesn’t mean they only do one of these things. It means that when compelled to act, people will feel more comfortable with a single approach, so if we look at coding, programming, or engineering (where you see lots of interconnected mechanisms balanced between “needs” and “wants”) people prefer Thinking (T) will be better at it. This post, titled “Does being an introvert make you a better coder?” puts it nicely:
“A typical software developer likes there to be a logical consistency behind a decision. It might not matter much what that consistency is, so long as it’s there. By contrast, other people prefer the ‘feel’ of the situation, using empathy and imagining what it is like more from other people’s point of view. In other words, there is a difference between coders and others, in how they tend to justify a decision.”
And as you can see, this has nothing to do with social preferences, or the ability to relate to people in any situation. That’s why this profiling system uses the word “extraversion”, referring to “the world of action, people, and things”, in contrast with “introversion”, or the world of ideas and reflection, both useful for doing complex things such as programming software.
“MBTI introverts prefer fewer, deeper, and more involved interactions with people, whereas extraverts prefer shorter and more frequent interaction. For getting to know users quickly, extraversion can be an advantage, but introverts are perfectly good at deep social interaction”, goes the cited blog. And it’s true; avoiding people has little to do with introversion, and the stereotype comes from misunderstanding what these words try to convey.
An alternative definition of the “introverted programmer”
So, to wrap things up, where does this leave the myth? As we said, maybe at some point in the past, before the development of agile methodologies or the normalization of a remote model of working, the stereotype of the “introverted programmer” was true and functional, but it no longer works that way.
People are more complicated than many of these systems will tell you, and lots of different preferences and abilities are desirable in any well-balanced team. What is true in the age of remote work, though, is that knowing how to interact and communicate well with your coworkers, clients, and managers at a distance are going to be a very valuable skill moving forward, and this has nothing to do with how one approaches the challenges of programming.
So we can leave behind all that and start thinking of the people best adapted to the work of programming in a different way; is no longer an introverted programmer, but a thinking one, whose intuition and affinity for code can be supplemented in a great way by social understanding and the clear communication that only the best Nearshore companies can offer.
