Staff Augmentation vs. Project-Based Consultancy—Which One Wins?

Bringing in an agency to help build your software platform is a winning strategy - it saves you time, and stress and most importantly keeps you within budget. But businesses often find themselves at a crossroads when it comes to outsourcing solutions. Two popular options—Staff Augmentation and Project-Based Consultancy—offer distinct advantages and cater to different needs. Let's delve into the intricacies of each approach and explore the benefits they bring to the table.

Staff Augmentation: Unleashing Flexibility and Scaling Capabilities

Staff augmentation in software projects refers to the practice of supplementing an existing in-house development team with external, temporary personnel or skilled professionals. This external workforce, often provided by an outsourcing or staffing agency, integrates seamlessly into the client's team to contribute specific expertise, skills, or resources needed for a particular project.

Staff augmentation strategy has a lot going for it, here are some big ones:

1. Greater Control and Flexibility:

Staff Augmentation is a go-to choice for businesses requiring temporary skilled workers or dealing with short-term projects. It provides greater control over the team, allowing seamless integration with in-house operations. The flexibility to scale the team up or down ensures that resources align with project requirements.

2. Immediate Access to Skilled Resources:

One of the standout advantages of staff augmentation is the swift access to a pool of skilled professionals. This is particularly beneficial for projects with tight deadlines, enabling teams to hit the ground running without the delays associated with traditional hiring processes.

3. Cost-Effectiveness for Short-Term Needs:

Staff Augmentation can be a cost-effective solution for short-term projects. While long-term costs may accumulate, the ability to bring in expertise only when needed can be a strategic financial decision.

4. Integration with Existing Processes:

Augmented staff seamlessly follow existing tools and processes within your company. This ensures a smooth workflow and integration with established methodologies, enhancing productivity.

5. Skill Enhancement for Ongoing Plans:

Ideal for developers familiar with project goals but needing extra support, staff augmentation aids in executing ongoing plans to scale. It provides knowledge of industry best practices and can contribute to achieving long-term objectives.

Project-Based Consultancy: Precision, Expertise, and Defined Outcomes

Project-based consultancy strategy in software projects involves engaging external consultants or consulting firms to provide expert guidance, strategic planning, and hands-on implementation for specific projects within a defined scope. Unlike staff augmentation, where external resources integrate into the existing team, project-based consultancy is more focused on delivering a comprehensive solution or achieving specific project goals.

Just like staff augmentation strategy, project-based consultancy has it’s upsides, here are some:

1. Expert Guidance and Implementation:

Project-Based Consultancy shines when businesses seek expert guidance and execution for specific projects. Consultants bring in-depth knowledge and experience, offering valuable insights that can elevate the project to market standards.

2. Defined Outcomes and Timelines:

Unlike staff augmentation, project-based consulting operates on a fixed or project-based cost structure. This clarity in financials and a clearly defined scope and timeline make it easy for businesses to budget and plan effectively.

3. Strategic Roadmap and Industry Compliance:

Project-based consultants provide strategic guidance in uncharted territories, ensuring adherence to industry compliance standards. They bring a fresh perspective, introducing efficiency to development processes and paving the way for successful project delivery.

4. Specialized Skills for New Challenges:

Consultants are aptly equipped to introduce businesses to new challenges. Whether it's accessing a new consumer platform or venturing into a new field, project-based consultancy helps enterprises apply their core talents to diverse and unfamiliar scenarios.

5. High Security Standards:

Consultants are expected to adhere to stringent security standards, providing a high level of data security. Their commitment to industry best practices ensures that projects meet the necessary privacy and security requirements.

Here’s the interesting thing, it doesn’t have to be one of those options! You could actually mix them up to bring out the best of both worlds.

Strength in Combination: A Holistic Approach

These two approaches need not be mutually exclusive. At Kaz we have have done many software projects where we have had both a dedicated team of developers working with our clients as part of their core team and separate parts of the system being built at the same time for that client in project based format. This gives our clients the flexibility and cost-control at the same time getting the benefits of the dedicated team. The added benefit of such a combined approach is that a component delivered as part of a project based work can then be looked after by the dedicated resource team (augmented staff) that has the benefit of co-located with the project team. This makes solving issues, knowledge transfer, future extension fast and accurate.

Also, initiatives that start as project-based consulting may evolve into more hands-on commitments, and vice versa. The combined strength of IT staff augmentation and project-based consultancy can lead to enhanced product responsibility, end-to-end support, and ongoing intellectual property advantages.

Code Reuse: Leveraging the Goldmine

Here’s a little fun comic we did a long time ago in Bangla, roughly translated it says, “Copy paste was designed by the programmers for themselves!” This was fun but there is an element of fundamental truth about this. Code reuse is one of the best practices in the software world if done right.

The importance of efficiency, speed, and cost-effectiveness cannot be overstated. As developers strive to meet tight deadlines and deliver high-quality products, the strategy of reusing existing software code has emerged as a powerful tool. In this blog, we'll delve into the myriad benefits of leveraging pre-existing code and explore how this practice contributes to the success of software development projects.

1. Accelerated Development Cycles:

One of the primary advantages of reusing existing code is the acceleration of development cycles. Instead of reinventing the wheel for every project, developers can draw upon the wealth of code libraries and frameworks available. This not only reduces the time required for coding but also allows teams to focus on the unique aspects of their project, leading to faster time-to-market.

2. Cost Efficiency:

Time is money, and in the world of software development, time spent on coding directly impacts costs. By reusing existing code, developers can significantly cut down on development time, resulting in cost savings. Additionally, leveraging open-source software and libraries eliminates the need to develop certain functionalities from scratch, reducing overall project expenses.

3. Quality Assurance:

Well-established, reused code has likely undergone rigorous testing and debugging. When incorporating existing code into a new project, developers benefit from the collective efforts of the original contributors, reducing the likelihood of bugs and errors. This enhances the overall reliability and robustness of the software, leading to a more stable end product.

4. Consistency and Standardization:

Reusing code promotes consistency and standardization across projects. Adopting a standardized set of libraries or frameworks ensures that developers adhere to best practices and coding conventions, resulting in cleaner, more maintainable code. This consistency simplifies collaboration among team members and facilitates knowledge transfer within the organization.

5. Community Support and Innovation:

Open-source communities thrive on collaboration and shared innovation. By reusing existing code from open-source projects, developers tap into a vast pool of knowledge and expertise. Community support can be invaluable when troubleshooting issues or seeking advice on implementation, fostering a culture of continuous learning and improvement.

6. Scalability:

Reusable code is inherently scalable. As project requirements evolve or expand, developers can seamlessly integrate new functionalities by building upon existing, proven codebases. This scalability not only streamlines the development process but also ensures that the software remains adaptable to changing business needs.

In the dynamic realm of software development, the value of reusing existing code cannot be overstated. Accelerating development cycles, reducing costs, ensuring quality, promoting consistency, and tapping into community innovation are just a few of the benefits that come with this strategic approach. By embracing the principle of code reuse, developers position themselves to not only meet the demands of today but also to adapt and thrive in the challenges of tomorrow. It's not just about writing code; it's about leveraging the collective intelligence of the developer community to build a more efficient and sustainable future for software development.

Living with Bugs: Navigating the Imperfect Landscape of Software Development

In the intricate realm of software development, bugs are not just an occasional nuisance; they are an inherent and inevitable part of the process. No matter how experienced or skilled a developer may be, the complexity of software systems ensures that bugs will emerge at some point. Rather than viewing bugs as obstacles, it's time to shift our perspective and acknowledge them as an integral part of the software development journey. Learning to accept and manage bugs is not a sign of weakness but a testament to the dynamic nature of programming. We wrote before about our philosophy of living with bugs in software that is already being used, today I’m going to delve into a more general view about dealing with bugs as part of the software development process - learning to live, accept and even learn from bugs that we create as we write code!

The Nature of Bugs

Bugs, also known as software defects or glitches, are unexpected behaviors or flaws in a program that prevents it from functioning as intended. They can range from minor inconveniences to critical issues that compromise the entire system. The diversity of bugs mirrors the complexity of the software itself, which is composed of countless lines of code, dependencies, and interactions.

Acceptance is the First Step

The first step towards writing great software is accepting the inevitability of bugs. Rather than viewing them as a failure, consider them as opportunities for improvement. Bugs are an inherent part of the creative and dynamic process of software development. Even the most renowned software products have their fair share of bugs. Understanding and embracing this reality is crucial for fostering a healthy mindset among developers.

“Industry Average: about 15 – 50 errors per 1000 lines of delivered code”

— Code Complete, Steve McConnell

In Steve McConnell's book, Code Complete, it is mentioned that the industry average for errors in delivered code is approximately 15 to 50 per 1000 lines. This metric is commonly referred to as defects per KLOC (1000 lines of code). McConnell further notes that Microsoft applications experience about 10 to 20 defects per 1000 lines of code during in-house testing and 0.5 defects per KLOC in production.

While achieving zero defects is possible, it comes at a considerable cost. NASA, for instance, achieved zero defects in the Space Shuttle Software, but the expense amounted to thousands of dollars per line of code. Such high costs are justifiable in situations where software bugs could lead to life-threatening consequences. However, for most projects, reaching the same level of testing rigor as NASA is financially challenging and often impractical.

Learning from Bugs

Bugs provide valuable insights into the intricacies of the software code. Each bug is an opportunity to learn, improve, and enhance the robustness of the system. By carefully analyzing bugs, developers gain a deeper understanding of the software architecture, identify weak points, and discover potential optimizations. The iterative process of fixing bugs contributes to the continuous refinement of the codebase. A great read is this article about strategies to handle defects in the agile methodology.

Here are some of the ways we can glean insights and improve from encountering bugs:

1. Root Cause Analysis: Investigate the bug thoroughly to identify its root cause. Understanding why the bug occurred is crucial for preventing similar issues in the future.

2. Knowledge Enhancement: Bugs often reveal gaps in understanding or knowledge. Use each bug as a chance to deepen your understanding of the programming language, framework, or tools being employed.

3. Code Review Practices: Regular code reviews can catch potential issues early in the development process. Analyze bugs to enhance code review practices and foster a culture of collaboration among team members.

4. Automated Testing Improvements: Enhance automated testing procedures to catch potential bugs before they reach production. Learning from bugs helps refine test cases and ensures better code coverage.

5. Documentation Enhancement: Document the bugs encountered, their resolutions, and the lessons learned. This serves as a knowledge repository for the team and aids in preventing similar issues in future projects.

6. Iterative Improvement: Embrace an iterative development approach. Use each bug fix as an opportunity to improve the overall codebase, making it more resilient and less prone to similar issues.

7. User Feedback Integration: Bugs reported by users provide valuable insights into real-world usage scenarios. Integrate user feedback into the development process to address issues that may not have been apparent during internal testing.

8. Continuous Learning Culture: Foster a culture of continuous learning within the development team. Encourage open communication about encountered bugs, solutions, and preventive measures.

9. Code Quality Metrics: Implement and monitor code quality metrics. Track the frequency and severity of bugs over time, and use this data to identify trends and areas that require additional attention.

10. Peer Collaboration: Facilitate collaboration among team members. Encourage open discussions about encountered bugs, and leverage collective knowledge and experience to devise effective solutions.

11. Adopt Best Practices: Incorporate industry best practices into the development process. Stay informed about advancements in coding standards, security practices, and technology trends to proactively address potential issues.

12. Incident Response Planning: Develop incident response plans to efficiently address and resolve bugs when they occur in a production environment. This minimizes downtime and ensures a swift recovery.

By approaching bugs as opportunities for improvement rather than setbacks, development teams can create a more robust and reliable software development process over time.

Effective Bug Management

While bugs are inevitable, effective bug management is essential for maintaining a high-quality software product. Over the years various processes and ideas have floated in the software development world for managing and reducing bugs. Six sigma management process is an example of such an idea of reducing bugs in a set software cycle. Agile methodology has definitely proven to be a very effective tool for managing and reducing bugs.

Here are some strategies to navigate the bug landscape:

1. Thorough Testing: Implement comprehensive testing practices, including unit tests, integration tests, and end-to-end tests, to catch bugs early in the development process.

2. Version Control: Utilize version control systems to track changes in the codebase. This allows for easy identification of when and where a bug was introduced, facilitating quicker resolution.

3. Bug Tracking Systems: Implement a robust bug tracking system to document and prioritize bugs. This ensures that the development team can systematically address and resolve issues.

4. Collaborative Development: Foster a collaborative development environment where team members can openly discuss and share insights about bugs. Collaboration accelerates the identification and resolution of issues.

5. Continuous Integration and Deployment (CI/CD): Automate the testing and deployment process to quickly detect and address bugs in the development pipeline.

In the ever-evolving landscape of software development, bugs are not adversaries to be defeated but companions on the journey toward improvement. Embracing the inevitability of bugs and adopting effective bug management practices are integral to writing great software. By viewing bugs as opportunities for growth and refinement, developers can transform challenges into stepping stones toward creating robust and reliable software systems. After all, in the world of programming, perfection is not the absence of bugs but the ability to navigate and overcome them with grace and skill.

I’ll end the post with a little comic we made in Bangla. The text translates roughly to - “Do you want write code without bugs? Then don’t even try!” This little comic sums it all up - you just can’t write code without bugs, you just have to learn to live with it to survive in this software development world.

Disagreements and debate: the crucial elements in great software projects

In the dynamic realm of software development, where agility and innovation are paramount, fostering an environment that encourages debates is not just beneficial—it's indispensable. The idea of debating within a software project may seem counterintuitive to some, as the conventional image of software development often revolves around quiet coding sessions and collaborative problem-solving. However, embracing debates in the development process can lead to a plethora of advantages, from refining ideas and uncovering hidden issues to enhancing team collaboration and achieving superior project outcomes.

Innovation through Divergent Perspectives

One of the primary reasons debates are crucial in software projects is their ability to stimulate innovation. Divergent perspectives, often emerging during heated debates, can catalyze the generation of creative solutions to complex problems. When team members bring unique experiences, insights, and approaches to the table, it opens up avenues for exploring unconventional ideas that could be game-changers. This realization has led to many software leaders actively seeking a diverse software dev team in the hope of inserting divergence in perspectives in team decisions.

Debates force individuals to articulate their thoughts, challenge assumptions, and present evidence in support of their ideas. This process of intellectual rigor helps in refining concepts and ensuring that the final solutions are well-thought-out and robust. Without debates, a team risks falling into the trap of groupthink, where conformity stifles innovation and unconventional ideas are overlooked.

Identification and Mitigation of Risks

Software projects are rife with challenges, and potential risks can lurk beneath the surface. Debates serve as a powerful mechanism for surfacing these risks and addressing them proactively. When team members engage in discussions about project requirements, design choices, or implementation strategies, they are more likely to identify potential pitfalls that might be overlooked in the absence of scrutiny.

By thoroughly debating different aspects of a project, ranging from technical decisions to project timelines, the team can anticipate and mitigate risks early in the development process. This proactive risk management is crucial for ensuring project success and preventing costly errors down the line.

Enhanced Collaboration and Team Dynamics

Debates, when conducted in a constructive manner, contribute to a positive team culture by fostering open communication and collaboration. When team members feel empowered to voice their opinions, it promotes a sense of ownership and engagement. Additionally, debates encourage active listening, as team members must understand and respond to each other's arguments.

Moreover, healthy debates provide an opportunity for team members to learn from one another. As individuals share their knowledge and experiences, it creates a collaborative learning environment where everyone can benefit from the collective wisdom of the team. This learning dynamic not only improves the skill set of individual team members but also contributes to the overall growth and development of the team as a whole. One thing important in this area is the leadership style of the team leads in the software project. If the style of leadership is not open to a multitude of ideas then the benefit of enhanced collaboration breaks down and the debates turn into points of division within the team.

Refinement of Ideas and Decision-Making

In the crucible of debate, ideas are refined, and decisions are thoroughly scrutinized. This process is essential for ensuring that the chosen path is the most effective and well-considered one. Debates force individuals to defend their proposals, encouraging a deeper understanding of the implications and trade-offs associated with different choices.

Through this rigorous examination of ideas, the team can make informed decisions that are more likely to stand up to the challenges of implementation. The act of defending one's position in a debate requires a comprehensive understanding of the subject matter, promoting a culture of informed decision-making within the team.

Continuous Improvement and Adaptability

Debates are not static events but dynamic processes that unfold as projects evolve. In the ever-changing landscape of software development, the ability to adapt and iterate is crucial. Debates contribute to a culture of continuous improvement by encouraging teams to revisit decisions, reassess strategies, and incorporate new insights and information as they emerge.

This adaptability is particularly important in agile development environments, where the ability to respond quickly to changing requirements is a key success factor. Embracing debates as a means of continuous improvement ensures that software projects remain agile, resilient, and capable of delivering value even in the face of evolving challenges.

In the fast-paced world of software development, where the only constant is change, the importance of debates cannot be overstated. By fostering innovation, identifying and mitigating risks, enhancing collaboration, refining ideas, and promoting adaptability, debates play a pivotal role in shaping the success of software projects. Teams that actively engage in constructive debates are better positioned to navigate the complexities of development, resulting in superior outcomes and a culture of continuous improvement. In the vibrant ecosystem of software projects, debates are not just discussions—they are catalysts for excellence. We have a joke at Kaz that if only two people agree in a group of many we have a decision! The little comic here says that in Bangla :)

Strategies to Avoid Analysis Paralysis in Software Development

Embarking on the profound journey of software development, one is quickly confronted with an elemental truth: there is no singular answer to any problem. This revelation, cultivated over years spent traversing the intricate landscape of algorithms, architectures, and enterprise platforms, is a foundational tenet of a seasoned software practitioner's wisdom. In this exploration, we delve into an extensive array of strategies, tips, and insights accumulated over decades to avoid the notorious pitfall known as "Analysis Paralysis"—a condition that has the potential to stifle innovation and progress within the realm of software development.

Analysis paralysis (or paralysis by analysis) describes an individual or group process where overanalyzing or overthinking a situation can cause forward motion or decision-making to become "paralyzed"…

Diverse Solutions, Diverse Perspectives: The Essence of Software Problem-Solving

The very essence of software problem-solving lies in the acknowledgment of the myriad ways one can arrive at a solution. Whether grappling with the intricacies of a simple algorithm or sculpting the blueprint for a sophisticated enterprise platform, every problem unfolds a cornucopia of potential solutions, each laden with its unique set of advantages and drawbacks. The challenge transcends merely finding "A Solution"; it involves navigating through the labyrinth of alternatives without succumbing to the pitfalls of perpetual analysis. The software development landscape is, at times, besieged by the affliction known as "Analysis Paralysis," wherein teams become ensnared in the web of alternatives, often resulting in indecision or, worse, a protracted stalemate leading to time depletion.

Ego: The Silent Saboteur in Software Development

The cardinal rule that stands as a beacon amid the complexities of software development is the imperative to divorce personal ego from professional discussions. Ego, oftentimes the silent saboteur, emerges as the biggest impediment to progress. The ability to detach oneself from ideas becomes a hallmark of seasoned developers. It is not about defending one's ego; it is about finding solutions. The moment discussions devolve into personal defenses, the focus shifts from the noble pursuit of creating value to the counterproductive endeavor of preserving one's ego—an unfruitful detour that hampers collaborative innovation. We are big fans of Ryan Holiday’s book about Ego - Ego is the Enemy

We are such big fans of the book that we have also made a video about it our books that software developers must read series in Bangla.

Standing on the Shoulders of Giants: Leverage Collective Knowledge

Design Patterns: Elements of Reusable Object-Oriented Software

By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

In a domain where problems often recur, acknowledging that others may have already navigated similar challenges is paramount. Leveraging the vast repository of knowledge available online, particularly through platforms like Stack Overflow, becomes a strategic imperative. The power of authoritative voices cannot be overstated; quoting industry giants and referencing proven design patterns can elevate a discussion from a mere exchange of opinions to a collaborative pursuit of well-founded solutions.

"In my view, the Gang of Four is the best book ever written on object-oriented design - possibly of any style of design." — Martin Fowler

The Power of Data: Informed Decision-Making in Software Development

Data, the bedrock of informed decision-making, is abundantly available in the software domain. Harnessing statistical data, survey results, and insights from scientific studies can provide concrete support for proposed solutions. From the impact of developers' seating positions to broader topics like software architecture, relying on reputable data sources becomes instrumental in guiding teams out of the quagmire of analysis paralysis. It transforms decision-making from subjective deliberations to an objective process grounded in empirical evidence.

The Personal Touch: Sharing Experiences as a Catalyst for Understanding

While data adds an objective weight to arguments, the personal touch of shared experiences provides a relatable dimension. Narratives from one's own journey, divested of ego and fortified by precise connections to the current context, can resonate profoundly with the team. Anecdotes become powerful tools when used to illustrate how past experiences align with proposed solutions, fostering a deeper understanding and connection among team members.

Embracing Open-mindedness: The Antidote to Rigidity

Acknowledging the absence of a perfect solution is not a concession but a realization of the dynamic nature of software development. No team can claim perfection, and staying open-minded becomes the linchpin for continuous improvement. An agile approach, marked by skepticism and a readiness to reassess decisions, helps navigate the ever-evolving landscape of software development. The ability to pivot and adapt, even after reaching a conclusion, ensures that teams remain agile and responsive to the multifaceted challenges that arise.

Testing the Waters: Prototyping, A/B Testing, and Surveys

In a realm where certainty is elusive, keeping options flexible is paramount. Teams can employ various strategies to test proposed solutions and mitigate the risk of committing to an unsuitable path:

Prototyping

Creating a low-cost prototype can be instrumental in testing specific functionalities or validating the feasibility of an approach. A quick test project has the potential to provide tangible insights, resolving potential bottlenecks before they become significant obstacles.

A/B Testing

If possible, running low-cost A/B testing can shed light on which of multiple solutions is a better option. By pitting two opposing groups against each other, teams can design low-cost tests to prove or disprove the effectiveness of different approaches.

Surveys

Engaging stakeholders, including customers or other software developers, through surveys can provide valuable external perspectives. Asking for opinions on proposed solutions or seeking feedback on the perceived technical viability can augment the decision-making process.

In the dynamic realm of software development, the ability to navigate through the multitude of solutions is an art. Freeing oneself from the shackles of ego, leveraging authoritative voices, relying on data, sharing experiences, and embracing open-mindedness collectively form a robust toolkit for steering clear of analysis paralysis.

As we continue to evolve in the world of coding, these strategies serve as a compass, guiding us through the maze of possibilities. In the end, it's not just about finding a solution but about embarking on a journey where every road taken contributes to the collective wisdom of the software development community. The software development odyssey is a continuous exploration, where adaptability, collaboration, and a commitment to learning become the sails propelling us forward into the uncharted waters of innovation and excellence.

Software: it's not for you, it's for your customer

The Crucial Art of Understanding Your Customer

In the dynamic landscape of software product development, there's a cardinal rule that often separates the triumphs from the tribulations: understanding your customer. The adage, "Your software is not for you, but for your customers," echoes through the corridors of startup wisdom, serving as a guiding principle for those seeking to navigate the complexities of bringing a digital creation to life.

The Costly Mistake of Losing Sight

Whether you're steering the ship as a startup founder or collaborating within a seasoned product team, losing sight of the end user's needs can prove fatal. It's akin to embarking on a journey without a map; the chances of reaching your destination diminish with each step taken in the dark.

Market Research: Illuminating the Path

Diving headfirst into comprehensive market research is the first beacon of light in this journey. It involves not just studying market trends but engaging directly with potential users. Understand their pain points, desires, and expectations. What keeps them up at night, and what would make their lives easier? These are the questions that form the basis of a foundation strong enough to withstand the tests of time.

Embracing Feedback: The True North

Feedback is the lifeblood of progress. Yet, many developers and founders shy away from it, fearing criticism or divergence from their original vision. This hesitancy is where the downfall begins. Embrace feedback, even the harshest critiques, as they are the keys to unlocking a product's true potential. Users, after all, are the most authentic judges of a product's usability and relevance.

Recognizing and Overcoming Biases

In the quest to create groundbreaking software, acknowledging and overcoming biases is paramount. As creators, we bring our own experiences, preferences, and assumptions to the table. However, these might not always align with the diverse needs of the target audience.

User-Centric Design: A Paradigm Shift

User-centric design is more than just a buzzword; it's a paradigm shift in approach. It involves stepping into the shoes of the end user, understanding their context, and designing a product that seamlessly integrates into their world. This shift challenges preconceived notions and ensures that the final product isn't a reflection of the creator's preferences but a solution tailored to the users' real-world challenges.

Personas: Bringing Users to Life

Creating user personas is a powerful technique to personify the abstract concept of your "customer." It goes beyond demographics, delving into the motivations, frustrations, and aspirations of fictional characters who represent your target audience. By crafting these personas, you build empathy and gain insights that can shape a product into something users don't just need but truly want.

The Process: Tried and Tested

As the saying goes, "To know thy customer is to know thyself." The journey of understanding your customer isn't a linear path but a mosaic of interconnected steps. Here are some key stepping stones:

1. Conduct User Interviews: Schedule one-on-one interviews with potential users. Listen actively, ask probing questions, and seek to understand the intricacies of their daily lives.

2. Utilize Surveys: Surveys are a scalable way to gather information. Craft well-thought-out surveys that touch on pain points, preferences, and user expectations.

3. Iterate Based on Feedback: Your product is not a static entity but an evolving one. Be prepared to iterate based on user feedback. Every critique is a valuable opportunity for improvement.

4. Test Prototypes: Before the full product launch, test prototypes with a select group of users. This provides real-world insights without the risks associated with a wide-scale release.

5. Leverage Analytics: Once your product is in the hands of users, leverage analytics tools to track user behavior. What features are popular? Where do users drop off? Use this data to refine and optimize.

A Warning Against Complacency

The ever-changing landscape of technology demands perpetual adaptability. Understanding your customer isn't a one-time task but an ongoing commitment. As markets evolve and user expectations shift, staying attuned to your customers ensures that your product remains relevant and impactful.

In the symphony of software product development, understanding your customer is the melodic refrain that resonates through every stage. It harmonizes market research, feedback, and user-centric design into a composition that strikes a chord with users. Embrace this cardinal rule, and your venture will not only survive but thrive in the dynamic and competitive realm of software innovation. After all, success in software development is not just about lines of code; it's about understanding the hearts and minds of those for whom the code is written.

Remote software team - setting up the collaboration

Remote software teams is way forward in software development. No longer are companies tied to particular locations, waiting for resources and skills to be available and delaying the entire software process. By finding the right software resource at the right time and forming a remote team to work with any onsite team completely changes the game - and companies that are realizing this are getting ahead in the game. This is just one more evolutionary step in our ever changing industry, a step that has just been accelerated by COVID but it was a step that was bound to happen at some time or other.

As with any paradigm shifts such remote software teams come with some adjustments in work practices and process. We’ve been working with hundreds of companies around the world for the past 18 years in providing software resources and hosting such remote software teams. Here are some our tips about the right setup for collaboration and workflow for such remote teams.

Setup a clearly defined work process

This may sound obvious but you’d be surprised by how many teams we’ve come across that just assumed things about the work process for collaboration of remote and onsite teams. This is understandable though, when a team works side by side many of the work processes are automatically defined and agreed upon without explicitly defining them. An example would be the timing a push of latest code into the shared repository - if the team is all together very soon a standard of when a push is appropriate and acceptable is agreed upon. A few wrong moves by a new team member quickly gets fixed by visual (and sometimes very audible!) ques from the rest of the team. But now imaging when part of the team is spread out remotely. The same mechanisms of automatic agreement doesn’t happen fast and sometime never. There is no way out on this, for teams with remote members the lead has to layout a clear set of instructions for major work processes. What the major elements are depend on the nature of the project and the team members but here are some that are obvious candidates:

Work timing - when to be available, when are good times for pinging without advance notice, when not to poke, etc.

Tools - defined set of tools for collaboration like issue tracker, IDE (specially versions of IDE)

Reporting standard - when to cry for help, when to warn about delays, what to report and what not to worry too much about, etc.

Testing rules - what should be the minimum set of tests on the developer’s side (even if unit testing frameworks are available for the CI/CD), etc.

Code repository rules - when to push, who can merge, etc.

Meeting rules - what tools to use, what are the good times for combined calls, how long the meetings should be, etc.

Create an open communications channel

With team members spread out geographically the open communications channel is essential for a healthy team dynamics. One common strategy is to have video call regularly with the video on (visual is very important forming the bond between team members). An awareness withing the onsite team about keeping the remote team members in the loop on all important decision making process is absolutely essential. Running regular video meetings is one of the best way to avoid issues caused by communication gaps and it has the added benefit of making the remote team members feeling valued. These video meets should ideally to be planned in advance and hosted at a time that works for everyone. A random last minute email to setup these calls isn’t the way to do it. Formalize at least a regular video meet by setting up a recurring invite so that everyone are reminded before each session.

Regular team calls should have the goal of keeping remote team members updated and also getting feedback. Remote teams should not find out about important decisions at the last minute. This has huge impact in lowering morale within the team members and would start creating a divide between the onsite and remote staff. If there is a new process change or some important company news a specially rededicated call aimed at all the members should be placed to keep everyone on the same page.

Use team collaboration tools as much as possible

For onsite only teams we always push for face to face informal interactions more than a very process and tool centric interaction. This is completely the reverse when the teams are spread out. In such teams you should aim to have all major collaboration purely tool driven. A good example would be work distribution on a issue tracker. For onsite only teams it’s usually great to have a quick ad hoc meeting to split a task and then asking team members to just create and assign the tasks to themselves - it moves the needle move faster and just feels less clunky, less “bureaucratic”. But doing this for remote teams is recipe for disaster. It’s best to rely on the tools, have as much as possible of the discussion on the tools (e.g. a discussion thread on the issue tracker, or slack, etc.).

It can be difficult to keep track of the progress and monitor the status of the project at every stage for remote teams. Using a great project management tool like Atlassian Jira is essential. Such a tool must have features for creating tasks and subtasks, assigning them to team members, tracking the task and setting time estimates for those tasks, etc. Such a system should also have a way for discussing details of task, a way to collaborate at the task level with a log of what is going on. Here’s a screenshot with an example of an ideal task ticket tool feature.

Software development with Unity

Unity is now a leader in games and any application that requires 3D visualization. It’s a platform that’s stable, has huge developer community support, great tools, very helpful documentation and an ever increasing software developer group - thus a superb ecosystem. Today’s post is an overview of this platform that we love and have been working on for several years. We’ll share our own experience along with a more generalized survey of the ecosystem for anyone thinking of moving to this space.

Unity the game engine

Unity started in 2005 with a very specific goal:

"democratize" game development by making it accessible to more developers

From the beginning the the focus has been on making a tool usable by everyone - be it in ease of use or be it in cost. And this focus has enabled Unity to achieve the great level of adoption it has now. Over the years Unity ecosystem has developed in to one of the most extensive in any programming ecosystems. Here are some of the big highlights of that ecosystem.

Multi platform support

Unity’s greatest feature is single code base that can target multiple platforms. So a developer can build an app for desktops, mobile devices like iOS or Android, Consoles like PS4 or Xbox, AR/VR devices, etc. all with the same code base.

Easy to use and learn

This is Unity’s biggest thing - it’s just simple to use. Within a very short time any software developer can have the environment setup and ready to create really complex games. Unity leverages on existing programming languages (C# and JS) and developer’s favourite IDEs. Thus the learning curve becomes very flat very soon. This makes the decision for trying out Unity for a software development project very simple as a test environment can be setup quickly and developers can try things out fast

Documentation, tutorials and templates

A big highlight for working on on Unity it’s support for knowledge. Developing a game in Unity is a smooth learning experience with accessible online tutorials and learning materials that Unity itself provides. This is then augmented by literally hundreds of other free tutorials and training resources from third parties. Specially valuable are the numerous YouTube channels dedicated to Unity development. It really helps an a new developer starting out her journey in the game development.

Video tutorials are particularly rich. Unity itself has hundreds of such video tutorials that go over in details of building fully working games. Apart from these tutorials and standard documentation Unity supports and continuously grows it’s library of template projects. These are backed up by even more templates from the Asset store (see below).

Awesome forums and community

Online forums are extremely strong for unity. The large community of Unity developers almost guarantees that any problem a developer runs into is already answered or can be answered very fast. Most of the larger forums are monitored by the Unity staff to support and answer questions directly from the makers of the platform. This overall support mechanism helps build the positive feedback loop of the community. Making it so strong. Unity’s own support portal: Answers.unity.com is a great example of how company supported public forums should be. Other forums include the good old stackoverflow’s Unity area, forum.unity.com

Rich marketplace for assets

The world of Unity comes with a marketplace where you can buy (or in many cases download for free) great assets (graphics, game objects, code, even full games). The Unity Asset Store is loved by game developers because it rich collections of pre-designed graphics, game objects and many more. The overall impact of having such a marketplace at your fingertips is the rapid pace of development in your project. Whenever you stuck for something - be it a new character in your game or some funky code or game logic you’ll probably find something in the assetstore to help you. This just speeds up your development by a large margin.

Flexible Licensing Model

Most projects and companies can start using Unity for free and then pay as they grow. That is the philosophy for Unity’s licensing. Most game engines are expensive have the most rigid licensing rules. This is just not the case with Unity. The Unity game engine, despite being a top platform remains at an affordable price, as compared to others. The free version has enough features get most of the common software projects and games off the ground and an upgrade to Pro version at a an affordable price brings in a whole pack of advanced features.

Analytics built in

Unity comes with built-in analytics that a game developer can use to setup their analytics. The engine is comprehensive and covers pretty much all the basic needs of analytics for discovering insights about the game and it’s usage.

With such great features it is no wonder that Unity-made applications were used by 2 billion monthly active users, with 1.5 million monthly creators! Unity is there to take over the game development space and it’s a platform to reckon with. So if you are thinking of working on a game or a software that requires 3D visualization then give Unity a spin.

Sourcing your software talents from around the world

A brave new world has arrived. A world where the age old concepts of work, workplace, office, meetings and all things related to work has changed forever. And I’m not talking just about WFH. Sure, work from home (WFH) or as some people prefer to call it “remote work” has become accepted, in some cases become permanent, but I’m talking about a much bigger thing than the acceptance of working from home. I’m talking about a paradigm shift in our way of doing work. The past two years (almost!) has forced this shift in us - in most case without us fully knowing. The paradigm shift is the idea that - work can be decomposed, spread out to talents who can do them anywhere in the world and re-composed. Any work can be split up into little blocks, and those blocks can be done by anyone, anywhere in the world and then those blocks can be put together and made into a whole.

This new paradigm works wonderfully in software work. Software development was half way there anyway, with teams spread out, tools of work (like the source control, servers) in the cloud, etc. But the pandemic just pushed the model further - specially to the skeptics (read management!). The formula for the new world in software projects is:

Step 1: Find talents anywhere in the world

You don’t wait for the talents in your neighborhood anymore. All you need to do is decide what skills you need to get the job done and then find a source for the talent online. There are freelancers and consultants available on sites like Upwork or Toptal or if you are looking for a more professional team that can take care of the whole blocks of things for you (and if need be the whole project) then you find a reputable company on a site like Clutch or you can rely on software company like us (shameless plug, but not too bad an advice).

Software is the same everywhere in the world - that’s the beauty of standardized syntaxes and compilers. So why wait? Treat the entire world’s software skills as yours to pick from - exactly like shopping from Amazon instead of your corner store!

Step 2: Bring them under your project’s virtual roof for a set period of time

The set period of time is the beauty of this new world. No longer are you tied to huge burn rates and HR overheads. You slot in the right skills at the right time and slot them out when their job is needed. If you can get the right partners and the right tools in place then it’s like magic - suddenly you have access to hundreds (if not thousands) of resources whenever you need them. It’s like being Microsoft on a puny budget!

Step 3: Get your software made!

Of course! This part is the same as before, well mostly. You will probably need to do a bit of composition with the blocks - that is bring the outputs together for the final software. In all likelihood you’ll probably do it the old style way but this too can be done in the new way of doing things and just relying on the resource cloud that you have in your hands!

The brave new world is great. The world is your oyster now. Happy software development.

Psst… if you want a great software team to help you make your software give us a shout at info@kaz.com.bd or just use box below to send us a message :)

Top 10 Questions you must ask your software vendor

Do you have any questions for your software vendor? You should. The standard stuff like what is the size of the vendor’s team, what are their skills, how long have they been around are usually available easily at the vendor’s website, their brochure or they are more than will to just give you that information. What is more difficult to know yet vitally important for you are the answers to the not so easy questions.

Here’s our list of top 10 questions that must be asked before any software development relationship is set up with a new vendor. There are obviously a lot more, but we feel that these 10 must be asked no matter what and the answers to these should be discussed internally with your team to see if you see a good fit, to see if you agree or accept those answers or not.

1. What are the company's values and goals?

You might think this isn’t all that important for you as a customer, or it’s just some marketing blurb that you can by pass - but you’d be wrong. A software development project isn’t like many other projects around, it’s not like a simple product you buy and then you can pretty much live on your own. A software development project means a sustained relationship for a period of time (usually pretty long - remember it’s just not the development time, but all the maintenance, updates, upgrades and fixes of a software’s typical lifetime) . So what your vendor’s values are, how they see the business, what their goals are - all these matter because you’ll need to agree with them, be comfortable with them and at the very least accept them. For example if the vendor feels that their real goal is to become a giant in 5 years, then you need to think if that fits with your goal of working with a stable and small team.

A picture from 17 years ago at our old office where we had those beautiful mosaic patterns you don’t see anymore.

Sometimes alignment of values are a very good sign that things will work out in the longer term. I remember a long time back I was showing a prospective customer our old office space that had these beautiful, intricate mosaics and I mentioned that we love these patterns and we take extra care not to destroy them somehow. She just absolutely loved it and said her company was a 3rd generation owner company that valued traditions - and we knew we had a good alignment. And indeed over time that has proven to be so true, having worked with them for a long time and launching several of their flagship products.

2. What happens when you fail to deliver something?

This is the hard question that all software vendor will try their best to avoid. But you absolutely have to ask. Things do go wrong in software (actually all the time, some studies have shown that 78% of software projects fail, a recent post of ours tries to find a way software project plans can be done to avoid failure). So asking how the vendor will manage that risk is essential. If the answer to that sounds vague or if they say the impossible - “we don’t fail” then think hard if this is a good fit, dig in deeper to see how reliable that partner is. Every software project should have a disaster recovery plan - simple. If a vendor doesn’t have one or isn’t planning one then there is something wrong with that vendor.

What you should be looking for is a realistic yet confident approach towards delivery failures. There should be a risk management plan - a risk containment and mitigation approach. They should be ready to act when a failure happens, and draw on the experience and knowledge from past projects and from the team to minimize the impact to the project.

3. What happens if a team member leaves suddenly?

Software is very much a team effort where every team member is essential. Over time a team member becomes an expert of the project and its requirements. Developers grow the essential familiarity with the codebase, the features, the decisions and the compromises that make a software project work smoothly and efficiently. So when a team member leaves it puts a huge dampening effect on the overall project and the vendor must have a good plan to first manage the team so that doesn’t happen and then manage things when it does happen.

More on this theme on question 8 below and there is a reason to separate them out and ask them a bit spaced apart. You want to revisit this topic to see if the answers fit well.

4. Can you provide case studies of customers who have been successful with your software?

5. Can I speak with a client who is using your product now to get feedback on their experience?

6. How many projects like mine has your company completed in the past year?

This is pretty standard stuff - but sometimes these case studies are not shared publicly. Maybe an NDA prevents the sharing or there are some other reason why they don’t want to put these in their marketing material. So it’s essential to ask and then review these case studies. These are projects that has worked out so you should get a feel of your own project fitting in those - see if you can imagine your project being one of the case studies in the future. Ask questions that are not answered or issues that are not clear in the case studies.

7. What's the best way to reach you during and outside normal business hours?

8. Who will be my point of contact throughout the project?

Standard questions but you’d be surprised how many customers don’t ask this. You should have a clear picture about what to expect when the project is running in terms of communications. All projects will have at least one point in its history where you are desperately looking for a quick answer to a question. It could be during an important demo that you are giving to your prospective customer, it could a bug you spotted that needs a fix right away. You need to know about the contact points and be absolutely sure before any vendor is accepted.

9. How do I know that I can trust you with my data?

Data security if everything in software and it’s important you ask this question right at the beginning. There must be a very clear procedure for data security at the vendor’s site. They must have a plan and a process that ensures that the plan works.

10. How long have your employees been with your company, and how many years of experience do they have in this industry ?

This is a revisit on the team stability question of question no 3. Vitally important question and a revisit is needed to see if the answer to this fits with the answer to the other.

Good luck with your vendor hunting!

All you need to know about bug reporting

Bugs are a fact of life in software. There will always be bugs, we just need to find a streamlined way of catching them, reporting them, fixing them and deploying a new version with at least that bug fixed. In this process of catching bugs and removing them from the software the role of bug reporting is vitally important. If not done right valuable time is lost in clarifying what the bugs was about and in the worst cases important bugs are either forgotten or deprioritized. This situation makes the software less usable and eventually if this situation continues the users stop using the software - which is effectively the death of a software. So today I want to go over one of the least exciting topics in software development yet one of the most important one - reporting bugs in a way that is effective, efficient and clear.

The bug report

The best bug reports are short with a step by step "how to recreate" section and an expected results section. It’s pretty easy to remember the rule for a good bug report. Every bug should have at least the following:

1. Steps to reproduce the bug.

2. What was the result?

3. What was the expected result?

By laying out the result and the expected result the bug report is clearly showing to the developer the gap. The developer can now use #1 to recreate the bug, look at the result and check why it’s not giving the expected result.

Here’s an annotated example of a great report from a really good post about how bug reports should be done.

Apart for the basic facts above, additional data such as screen grabs and links to the product page are always good to have. Something else that also matters is the context of the bug - if there was a special situation when it happens (ideally that should be part of the steps to reproduce, but sometimes it may be hard to put that in there). If your bug is related to a specific hardware device and you should attach your device ID, it helps the developers find the bug faster and fix it sooner.

Including as much detail as possible makes finding and fixing your bug faster, remember that when reporting the bug the state of the software may be completely different from the time when the bug is being re-created and fixed. Many times a bug that was reported cannot be recreated by the developer. The reason could be that a step was missed in the bug's description or the state of the software at that particular situation needs to be in certain way for the bug to recreated. I remember a particularly nasty bug that would only happen at the QA's machine but never on my dev machine. The reason was that the QA would always run the web app by clearing his cache which would create a situation very different from my one where a certain cookie was always set. So the bug was really about not managing the cookie's absence.

Sometimes there could be many bugs that you report without realizing it. For example if the application is doing something wrong in a situation where you expect it to do something different and you thought you had reported the only bug and then discover another one after some time, chances are that your first bug was actually two separated ones and not one big one. The QA needs to think through every bug to see how it happened.

As you can see, describing a bug is not as easy as it looks and chances are that if you report a bug like this: "I opened the app and clicked 'login' but I was on the 'welcome' screen and there was no way to go back", then it will be impossible for developers to fix that. And it will end up spending everyone's time.

The process after the report

After submitting your bug report in an issue tracker, it should first be picked up based on severity of the bug. If the bug is a show stopper, a bug that stops the software from working then it should be prioritized over all other bugs and if needed current development flow will need to be changed to fix the bug so that it hits the next release. If it happens not to be a show stopper but just an inconvenience, then it gets bumped down the list and is fixed over all other bugs that are also being worked on. The issue tracker should be available to the original reporter of the bug (maybe the QA person or even the user of the software) who can easily track it down and see the status of the fix.

Another important thing with a bug report is the history of the bug. Every bug should show when it was started, what happened during it’s fixing, the exchange in information that happened to clarify the bug and finally the fix and the confirmation of the fix. So a history of the workflow per bug is a must and every software development process should use an issue tracker that supports such history. The good news is most modern day issue tracker such as Jira, Github, fogbugz, etc. support this buy default. Even the simple trello board is good for this.

How to evaluate software development company performance

Do you find that your software development company is taking too long to deliver a project? Do they lack creativity and innovation? Would you like a partner who can provide accountability and transparency in their work? If so, read on.

As a custom software development company that have worked with hundreds of clients all over the world we have come across all kinds of situations where multiple parties are involved in creating a software platform. The performance of each party is crucial for the overall pace and success of the software project. And we have advised our customers about how to monitor and assess performances of their vendors - including ourselves! In today’s post I will summarize some of the biggest tips we have for our customers to assess the performance of a software developer.

The basics

In order to evaluate the performance of a software development company, there are four criteria worth considering:

speed, price, quality & service

Here's how these factors stack up for one of our clients:

-Speed: Slow delivery times lead to lost revenue as well as frustrated customers. Our client has already seen an average 30% increase in productivity from the new vendor we partnered with them on this project.

-Price: You get what you pay for! The old adage applies here, however there is a big mitigating factor here - location. If you are using a vendor at a relatively lower cost location such as ourselves based in Bangladesh you have the opportunity to find a price that is lower without compromising on the quality.

-Quality: This is the the most important one. In the world of software the only thing that really matters is quality. And you could compromise on pretty much all the other factors but not on the quality.

-Service: How’s the requirement analysis, the communications during the build, the delivery, the promises kept and the promises broken? All of these go towards the service metric.

The performance measurement matrix

The performance measurement is not a linear operation. That is to say it is not a single number you are looking at. For example a company that is great at quality might be really poor at speed. Does that mean it’s a badly performing vendor? The only sane way of getting a full view of the performance is to create a matrix that goes over the issues at stake and measures each one of them against the four basic dimensions of performance mentioned above.

One thing to note before I jump into this: there are hundreds of “scientific” way of measuring performance of a software development vendor. This is a topic that is favourite with efficiency specialists, university computer engineering departments and large multinationals with huge investments in IT. If you really want to get to know some of the research work that is done in this space a great starting point is the highly academic yet useful book generalized towards engineering organization performance: Performance Measurement and Management for Engineers or if you prefer a google search will lead you to a pages and pages of approaches towards measurements. What you’ll soon learn is that there is no standardized foolproof way to do this. At the end you end up with a lot of hand wavy metrics. All the big names in software has said something or other about the futility of measuring performance in software projects! Here’s one I like a lot:

“So while I see the value of measuring individual performance in research settings, I think its difficult to find cases in which the effort is justified on real projects.”

— Steve McConnell

OK, now that I’ve got that out of the way, let me go over what we suggest. Our approach is pragmatic. We accept that no measurement scheme will be perfect, so all we can do is layout some basic information in a way that’s easier to visualize and let project owner do their own assessment based on that. So that leads us to the matrix I was referring to.

The columns in the matrix are the four basics - speed, price, quality & service and on the rows are the questions or issues that matter to the project or to a particular company. In this super simple method we take away the pain of running elaborate surveys, questionnaires, software line of code analysis etc. that some approaches use and use a very intuitive way of quickly getting to some feelings about the overall performance. Note that the number of rows, that is the issues, actually vary project to project, company to company. And that makes perfect sense, what matters to one project may not be an issue at all to worry about in another.

Here’s a sample matrix that we did for one of our customers recently. They had a total of 28 issues that they tracked with this, beyond the ones shows in the screenshot the rest were specific the product features, stuff like “All screens should update with animation”, etc. These made sense for this particular customer as they thought this was essential for the assessment of performance, but for many other companies such a granular level or such a narrow scope for the assessment wouldn’t make sense. That is the beauty of a simple matrix approach such as this one - it is flexible and can be adapted to the need of a specific project/customer/vendor situation.

When it comes to evaluating software development company performance, there are a number of factors that can help you determine if the vendor is working in your best interest. I’ve outlined our suggested way that seems to work very well for software projects. You can use this at regular intervals (we suggest every 6 months) to check the performance and detect signs of change. The change in scores from previous ones give you the signs of a change in performance - for the better or for the worse. Do any of these signs apply to your current vendor? If need help give us a shout at info@kaz.com.bd to learn how our team might be able to help you.

10000 hours of practice - fact or fiction?

It all started when Malcolm Gladwell published yet another one of his blockbuster books - Outliers. One of the ideas in the book was put in enough practice and anyone can be an expert of anything. In the book, Gladwell states that:

“ten thousand hours is the magic number of greatness”.

Outliers is one of those books that really motivates you, and this idea that you don’t have to be a born genius to become a good at anything is one it’s biggest uplifting moments. Gladwell quotes several studies and gives examples like starting really early and getting those 10,000 hours of practice made the Beatles become the greatest band in history. For example, between August 1960 and December 1962, the they played over 250 all night shows in Hamburg, playing four to five hours a night. This racked up their practice numbers, Gladwell argues, refining their skills leading to becoming the best. John Lennon him self is quoted as saying “In Hamburg we had to play for hours and hours on end,” he said. “Every song lasted 20 minutes and had 20 solos in it. … That’s what improved the playing.”

Is it a fact?

But is this true? Does putting in 10,000 hours into anything makes you the expert? Specifically, for us software people, we can ask “can anyone become a top developer by putting in 10K hours of programming?” Well for a start we all know that the more you code the more you become good at it. It’s one of the first advice we give to freshers or students when they ask about career improvement. There is absolutely no doubt practice makes a man perfect in the coding world. But the bigger question is, can anyone without any coding experience jump in and put in those 10K hours and become the best? This is where you’ll see a lot of dispute. In our experience, some people just are good at logic, or at looking at new ways of solving a problem, or thinking out of the box to find amazing way outs from knotty technical issues. If you start with one of those people and push in the 10K, yes for sure you’ll end up with a world class software developer. But if you start with someone who is not good at logic or just has a different way of thinking that get him into complexity all the time, I fear the 10K will not work so well. So I guess my answer is:

“it depends”.

This “it depends” seems to be in other fields too where the 10K rule is getting debunked. The original science behind the 10K rule was the 1993 paper by Ericsson et al. : The role of deliberate practice in the acquisition of expert performance that studied violinists and their achievements. But a recent study done to check those results found gaps and also the fact that beyond a certain level of achievement other factors came in to make the role of practice less clear.

10K hours of coding?

Let’s say that the 10K rule is a fact. Is it something we can actually do and become the greatest coder around? How long would it take? Let’s do some quick maths

If you wanted 10K hours of coding in 1 years you’d have to do 27 hours a day. So that’s impossible (unless you start approaching light speed and time dilates a bit for you).

If you wanted to do it in 5 years, you’d need to code 5.4 hours a day, 7 days a week. Kind of do-able if you want to loose all your social life. I actually know about someone who did/does something like that. He is definitely one of the best coders in his area, but has lost most of his life and family to the art of coding… so not sure if that was such a good move.

If you wanted to do it in 10 years, you’d be coding 2-3 hours a day, 7 days a week… now this is entirely possible and should be the recipe to make it big in the coding world.

So fact or fiction, coding 10K will improve your skills from where ever you start. Aiming for a reasonable 10 year plan with coding hours fitted in there almost everyday is something every aspiring coder should plan for. And read the book, btw, we are going to do a quick book summary soon about it!

Data privacy regulations 101

Data privacy is obviously very important. With large companies gather huge amount of data of it’s users and with the great advancement on data mining and data analytics technologies data privacy has become one of the biggest concerns for all consumers. If you are not that concerned about this, you should be, here’s a quick read to get your concern raised - a quick survey of what data FB or google already has about you.

This concern is reflected by the various regulatory bodies and governments stepping up their regulations about what companies can do with the data, how they can share it and how they have protect it.

The problem is that the online world has not autocracy! And in those rare cases in this world where autocracies are great this is one place all software creators wish there was one single autocratic power giving out a single set of rules to abide by :) Sadly that’s not the case and a software developer that wants to serve customers around the world (i.e. every software company in the world) now has to understand a plethora of data privacy rules and regulations, create interfaces for seeking consent, show text for displaying warnings, create processes for managing the security and the privacy. This is why every website we visit today has a confusing range of popups, highlights, texts, footers and headers asking us to accept this or decline that or warn us that we will lose our soul if we don’t do this or that. In general, all this chaos has just created a fatigue in the consumers who just click accept where ever they see it just to get to the page. But that is another story.

Today’s post is for the software developers and software founders who wants to get a quick overview of where things stand now and how to navigate in this jungle.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a Privacy, Security, and Breach Notification Rules protect the privacy and security of health information and provide individuals with certain rights to their health information.

If your software has anything to do with healthcare, medical services even pharmaceuticals and drugs you should be concerned about HIPPA compliance. It’s a US standard but complying with this basically ensures that you comply with any of the national rules you are likely to encounter in other countries.

Software developers play a vital role in protecting the privacy and security of patient information that comes in through thousands of software systems and interfaces in an increasingly digitalized healthcare world.

At its core HIPAA is pretty simple and based on the following 3 parts:

• Privacy

  This deals with protection, authorization and access. It sets rules for when and how any personal health information can be disclosed and used. It also gives users the ownership of their health records, the right to access them and request modifications as needed.

  So any system you develop needs to have the flexibility and security built on top of the data store.

• Security

  This is the obvious section on the standards for the security of technology used to access, store, transmit, or process any personal health information. This part is the big thing that you as the software developer need to focus on. Certain implementation specifications are either required, meaning that its mandatory to build them in your software, and some are addressable. Addressable are ones in which either you need to 1) implement the specifics as written, OR 2) implement an alternative solution, OR 3) not implement anything for that specific requirements because it is not reasonable or necessary to do so. As with most things in HIPAA, the important thing is that decisions related to addressable specifications are documented.

• Simplified Process

  This part relates to the accepted coding for data exchanged in healthcare. The transactions this applies to are financial related (claims, eligibility, enrollment, etc). To comply with this part you have to make it administratively easier to exchange data by not having to keep track of an endless number of code sets. (What’s a code set?)

GLBA

The Gramm-Leach-Bliley Act (GLBA) is a US law for control on personal financial data managed by financial institutions, and how these institutions deal with a consumer’s non-public personal information (NPI). There is a lot of very private personal financial data that organizations like banks, insurance companies etc. collect when providing a financial product or service and GLBA is the overarching rule that gives users protection on the use of that data.

If you have anything to do with a fintech app or any platform that is used by a bank or an insurance company it’s very likely you’d need to know about GLBA and comply with the it’s guidance.

From a bird’s eye level GLBA has three main parts:

• Privacy Rule

  This regulates the collection and use of NPI. This is the part you as the software developer need to focus the most. It’s pretty comprehensive and there are lots and lots of issues that you have address in this area - so you’ll need to spend time in getting to know the rules. Wikipedia article on the privacy rule does a good job in getting you a quick background.

• The Safeguards Rule

  This part requires financial institutions to implement a security program to protect NPI. So this more on the side of the institutions and their network but doesn’t stop just at physical security so intelligent monitoring of data and transactions is something software developers will probably need to integrate with other solutions within the infrastructure.

• Pretexting provisions

  This prohibits access to NPI under false pretense and is more of a legal concern for the organization and it’s workflow processes. As a software developer you will need to ensure access control and several layers of authorization and monitoring of access.

COPPA

Children's Online Privacy Protection Act (COPPA) is a set of rules that prohibits online software such as websites, apps and games from collecting personal information from children without first providing notice to parents and obtaining their consent. The rule also provides parents with the right to find out about stored data collected from or about their children, and to refuse further data collection and use.

If you are building any software that is primarily directed towards children then you need to be aware about COPPA. Although a US rule it is a rule that was used by most national rules to create their own children protection acts. COPPA is super important for game developers particularly for mobile games - as any failure may lead to a permanent ban from platforms such as apple appstore or google play. Here’s a great primar for game developers

If you didn’t know the story, a recent example where COPPA non compliance led to a big fine was Tiktok, which was fined $5,700,000 in February 2020

Here’s a bird’s eye view of different parts of COPPA you need to be aware of:

• Privacy Policy

  You need a clear and detailed privacy policy and it must be linked clearly on highly visible location within your application, especially where personal information is collected. The privacy policy need to include all information you collect from children, details about how such which the information is used, and whether it is shared with any third parties. You must also reveal the names and addresses of the owners of the software so that may be contacted by parents.

• Parent Opt in

  You need to provide parents of the child user with a message and obtain their consent before using personal information of their child. You need to tell parents that you collected information about their children, describe the information, explain what manner it may be disclosed, and that parental consent is required to do so, and also provide a link to your privacy policy, provide a way to give consent, and let them know you will delete their information if you do not receive their consent.

• Disclosure to Third Parties

  If any information collected by the software will be disclosed to others, you will need to provide a stronger method for consent, such as a signed form, or a contact number. After giving consent, parents must have access to the data for reviewing and deleting their child’s information.

SOX

Sarbanes-Oxley Act (SOX) is a set of regulations that sets the compliance needs and deadlines for public companies. SOX came out necessity when corporate America was broiled with scandals from giants like Enron, WorldCom, and Tyco. The regulation protects the general public and shareholders from accounting errors, fraud in enterprises, and it helps to improve the accuracy of corporate disclosures.

SOX is a big responsibility for public companies but for software developers there is a need to understand the basics so that the systems they build and more importantly the process they follow comply with SOX. If you are employed by a public company in US you should be aware of SOX and as with the other regulations complying with SOX probably means you comply with other national rules modelled around SOX. One of the most important thing for software developers for this regulation is that a software developer should not have any kind of write access to production systems that can affect the financial reporting of the corporation. This is not always easy to comply with and you require a proper process which separates roles of development from system administration to achieve this.

Remember SOX precludes software developers from administrating of systems they write.

Here are some of the main areas of SOX that you should know about:

• Responsibility

  Top management is directly responsible for the accuracy, documentation, and submission of all financial reports. CEOs and CFOs risk imprisonment and penalties for failures. Phew… it’s all on the bosses here unless you are one of them :)

• Internal Control

  Adequate internal control structure for their financial records. Any shortcomings must be reported up the chain as quickly as possible for transparency. As a software project lead your responsibility will be to identify lapses or possible gaps in the reporting structure for software failure.

• Data security policies

  Policies for data security and consistent enforcement of those policies is the key requirement. Companies need to develop and implement a comprehensive data security strategy.

• Independent Audit

  Companies need to maintain and provide documentation proving they are compliant and that they are continuously monitoring and measuring compliance for independent audit. This is where the software developers get involved a lot, as they are the ones that have to build audit logs, configurations, versioned histories of data, etc. required to comply.

GDPR

This is the big one, specially because of wide adoption and the fact that it’s recent. The General Data Protection Regulation (GDPR), agreed upon by the European Parliament is a European Union law that creates new rules for companies that offer goods and services to or that collect and analyze data tied to citizens of the European Union.

As EU citizens are a sizable portion of any application available online (which is every app out there) you as a software developer will need to comply with this rule. It’s pretty detailed and has all sorts of side rules to satisfy the multiple national rules within EU. As a developer you probably don’t need to know all the details to it’s fullest but here are some that you should be concerned with.

• Consent

  GDPR requires that all software you write seeks consent from the user before collecting any information. An explicit consent by statement or action signifying agreement to the processing of their personal data needs to be clearly laid out to the users. Remember that data here is wide enough to cover even cookies (and hence all those “accept cookies” forms we see these days).
  
  

• Access control

  This gives the right to the user to have access to the data that is stored in any organization. As a developer this has the huge implication of making it flexible to access data even historical ones when the user requires it.
  
  

• Data Portability

  This requires the organization in control of the data to provide the data in a format that allows for easy use with another controller. As a developer this boils down to following standard data exchange formats

• Right to be Forgotten

  This entitles the users to have the a company erase his/her personal data, cease further dissemination of the data, and potentially have third parties cease processing of the data. And for the software developer this means creating interfaces and technology that makes this possible. One huge concern for the software people in this space is that a delete essentially mean a full delete from everywhere - including historical files, backups, shadow copies, the full works.
  
  

CCPA

This is the new kid on the block and as such is becoming the new thing that every software developer is getting worried about.

California Consumer Privacy Act. (CCPA) went into effect on January 1, 2020, with a six-month grace period for companies, giving them time to comply. If a company doesn’t comply, Californians can file private lawsuits pursuing civil penalties for violations. And as California owns the software world every software company in the world are reading CCPA carefully!

For software developers the good news is that if you are covering GDPR many of the issues on CCPA is also covered, although not perfectly. So you’ll still need to double check. Here’s a great article that compares these two: GDPR vs. CCPA here’s a screen grab from there comparing them:

Software team structures

A common question we get asked by new companies in our field is:

What’s the best team structure in a software company?

Our answer to this question had been an easy one: “as flat as possible” meaning a structure where there are that many levels - ideally no middle managers just the software developers or other technical roles reporting directly to the team lead who barely ever needs to report to anyone above.

This is a great answer. It takes away the biggest problems in software development companies and introduces creativity, ownership and most importantly collaboration. But this answer is by itself not good enough. As a company grows, as it takes in more and more projects requiring larger number of teams which then collaborates with each other the flatness that gave all the flexibilities in a smaller organization starts to introduce confusion and chaos. So some more structure is needed. What that ideal structure might be is a question that’s very specific to the nature of the company in question and the culture that it embraces. For us at Kaz it’s been moving towards more independently operating teams that operate under groups or wings of technology. We call them companies under companies under companies. This may not work for everyone. Today let’s go over some common software roles we hear about and try coming up with generalized views about what those roles are supposed to do. This might give us some ideas about what roles our own companies might require and where to fit them.

Common Software Roles

Some of the common software roles we see in the industry worldwide are as follows:

Chief Technical Officer (CTO)

CTO is a confusing role, it’s a role that requires purely technical skills most of the time but sometimes it needs to be as non-technical as can be. At startups, the CTO is often a technical cofounder and that role is all about jumping into coding and jumping out to join a marketing meeting. But the same CTO role is a large organizations is very different. A CTO at such an organization is mostly outward facing - looking at clients, product and marketing teams and giving a voice to technical angle on all business conversations. Rarely does a CTO at large organization ever dive into the code or even participates in technical architecture. They participate in business development meetings, frequently helping to land large partnerships or sales. Many spend a lot of time evangelizing the development activities of the organization to the wider world: sharing the company’s innovations and discovering opportunities in the market which match up well with the company’s core competencies.

VP of Engineering or Director of Engineering

The Director of engineering’s role is what most people usually think of CTO’s role. This role is frequently responsible for building the engineering team, creating work process of the technical team and establishing the engineering culture and operations. While CTOs often face outwards - towards business and clients, the Director of Engineering faces inward - towards the technical workforce, their daily needs.

The best directors of Engineering constantly monitor the team’s progress, process and culture. She encourages the technical staff to use the right tools, the right platforms, even the right programming libraries. She may have strong views about how the teams should operation, how the meetings should be run, hold specific kinds of meetings at specific times in order to foster better collaboration with fewer interruptions.

In smaller organization it doesn’t makes sense to increase hierarchy by having separate CTO and director of technology. These two roles can easily be fused together in such organizations but as soon as business starts to expand this is one role that needs to split first.

Chief Architect & Software Architect

The architects in a software organization are usually the uber geeks. They are the super star programmers who never wants to be in any kind of management role and want to stay as close to coding as possible. In small organizations, the chief architect is sometimes the technical co-founder who knows that she never wants the responsibilities of a CTO as the company grows. They are just not interested to take all the hassles of customer facing, project facing, investor facing and team management facing responsibilities that comes with the CTO or even the director of engineering roles.

The architect is the person responsible for selecting technology stacks, planning technical solutions, designing collaborations and interfaces between systems, etc. As the company matures, the chief architect may also need to work closely with the CTO and at many companies, the CTO also serves as the chief architect.

Project Manager

This is the big difficult role. Sometimes this is the role that everyone in company is looking at. In most companies this is the role where a technical staff decides the future of her career - does she want to stay in development and aim for architect roles or does she want to go more towards management roles.

A project manger is in charge of managing the workflow of an engineering team. She interfaces with both product leaders and an engineering leader such as director of Engineering or the CTO to manage the work backlogs, monitor the progress of tasks, create detailed progress reports, track milestone, manage burn down charts, etc. In smaller companies the project manager is the multi-hatted role of a director of technology and team lead.

Technical Lead/Team Lead

The Team Lead is the leader of a small number of technical staff that forms a particular team in the project’s workflow. Typically a team lead is a senior engineer who takes on the role of mentors and guides for the rest of the team. Usually, developers report to a team lead who then reports to the project manager to give a summary of what his team is doing. The team lead is usually coding all the time and the team lead role is a more a part-time role she has to take up when the time comes. In some companies she may be responsible for the team’s code quality, code reviews and managing the team’s output standards.

Various software engineering roles

At the team level are the real workers in a software company - the people who really make it all happen. Based on different levels of experience you have some of the following roles.

• Principal Software Engineer

• Senior Software Engineer

• Software Engineer/Developer

• Junior Software Engineer/Developer

• Trainee Software Engineer/Developer

These are the people who gets things done, who write the code according to spec, fix bugs and creates solutions to problems.

So these are some of the basic roles. But what happens when we look at the giants like MS or Google? With technical teams that are size of small towns obviously having just few levels in the roles isn’t enough. So for Software Development Engineering (SDE) roles there are hierarchies and more levels and structure. Just to get a glimpse, I’ll close it up today with a comparison of the software roles at our 3 giant friend’s.

Introducing new features in your released software

Imagine this: you have released your software. As with any software releases, you had cut corners, last minute compromises had to be made, features had to go out without all the bell and whistles, etc. Yet, you users loved the software, and they have started to use it. As you start getting new users, you are also starting to get requests for features you had compromised on during the release. And people are complaining a bit about the UX, there were things you had thought made sense but it’s not so obvious for your users. You now realize that you have to update your software with a new version.

The good news is that it’s a web app, so updating is just releasing a new version overnight, making sure people’s data isn’t lost and you are done. But the bad news is that your UX fixes and new features mean you’ll need to revamp how the software will be used and the interface is likely to be completely redone. It’s bad news because you know that some people will get confused with your new UI because they’ve learnt your current interface and are using it.

What do you do?

Here are some strategies that we’ve been advising our clients with and they come from working on hundreds of app releases and update.

Release often, but only at the start

“Be agile; release early; release often.” that’s the the drill. But it is strategically wise to keep rolling out features only at the beginning of a product roll out when you don’t have that many users. When your product reaches a certain size, a certain number of users, you don’t want to risk the integrity of your application with every new minor release. The worst thing that can happen to your product is that loyal users, customers who have been using that one little feature consistently over the years, suddenly aren’t able to use it in the same convenient way. The change might empower users more, but the experience becomes less straightforward. Frustration and anxiety enter social media quickly and suddenly, and the pressure on customer support to respond meaningfully and in time increases with every minute. Of course, we don’t want to roll out new features only to realize that they actually hurt loyal users.

So the plan should be:

Release early, release often only at the beginning of product’s life

Announce the release

You should have a list of its current users. Use that list to communicate that changes are coming so people are prepared. Plan on sending an email announcement, explaining your new upcoming plans, with dates and list of feature changes.

Create a video showing what’s going to be new and more importantly how it will improve things for your users. Remember, this not just a boring news of updated software but it’s an advertising to get your users excited about the new features. That excitement will help ease the pain of learning and adapting to the new interface or the new way of doing things. A lot of people are visual learners and this preview will make the changes feel less unknown the next time they use your software. Sometimes even a animated gif does the job well. Here’s google introducing a new feature with a very short animated gif.

Or basecamp doing a in app popup letting people know about changes that are about to happen. Trello does something similar with their “New stuff!!” fox at the top.

Have app Tours & Walkthroughs for new features

When your users use your app all day long a new update can greatly affect your efficiency. You can easily address that negative by providing a short and easy in app tour to re-teach user behavior and help users with missing or moved features. There are different types of tours, but the ones that point out and walk users through how to use a new feature and answer any common questions works the best in our experience. Gmail has a great one that you must’ve seen. Here’s one I saw recently that I liked.

The good news is that it’s easy to add these in app tours. There are several great products out there that makes it pretty easy. Try out Stonly or Intercom for a start.

Have a “I’ll try later” option

This may not be the easiest option from a dev point of view, but it would be wonderful if you can do it somehow - the option that let’s users use the old interface for a while. Very useful when your users have something urgent to work on and you come in with your all new shiny interface where nothing is where it was! Facebook has them all the time when they do their big UI shifts, but they are Facebook. But you don’t always need thousands of developers in your team to do this. Nifty tricks like having the older version still available on a server and click to redirect users to that version might suffice in some cases :)

Ask for feedback

Sometimes all it needs for your users to be OK with your changes is a simple “sorry for the changes, we welcome your feedback” message somewhere. This humanizes the software and let’s your users know that you are putting them in trouble and that you are willing to listen to them.

Remember how angry we would get every time MS would drastically change their interfaces? We learnt the new way of doing things but we were looking for some way to tell MS what then shouldn’t have done!

Anyway, software is always going to be updated, so you’ll just need a way to make those updates less obtrusive to your users. This is a fact of life! Happy software development…

Living with bugs in released software products

Bugs are the reality of software. We hate them, we do everything we can to get rid of them but they are always there and we have to learn to live with them - that is we have to manage the bugs and fix them in a sane way. This is important. Actually trillion dollar important. in study done by the Austrian software testing firm Tricentis, software failures cost the worldwide economy over $1 trillion annually!

The same report also found that software failures have caused more than 315 years of lost time and have affected approximately 4.4 billion customers. Software failures also have a massive negative impact on the reputation of companies. The companies surveyed by Tricentis lost an average of $2.3 billion of shareholder value just on the first day after announcing a software failure. No wonder that so many companies keep quiet about bugs. Yet that is probably the biggest mistake. The trick is to learn live with the bugs as a reality and have a practical and realistic process for managing bugs in live products. Today’s post is an attempt to summarize some of the strategies we found as the best for managing bugs on live products.

Accept bugs

This may sound obvious, but you’d be surprised how many companies treat bugs as something totally unacceptable and creates all kinds of penalties and punishments when bugs start surfacing on a product. This behavior comes from not understanding the nature of software products. Yes, the goal is always to have a bug free software release, but the reality is that there will always be some. So the goal should be:

“Release with as few deadly bugs as possible”

Accepting bugs opens up the possibility of a realistic software development process with healthy bug identification and resolution strategy. So this is the first step - for the management and for the technical team leadership.

Make finding and reporting bugs easy

Real life story:

A group of security researchers were prepping for a major reveal in 2013: They planned to disclose at a D.C. cybersecurity conference how a security flaw in luxury vehicles could let bad guys break in without keys and start the cars.

But Volkswagen stopped them, winning an injunction in a British court after arguing that publishing a paper detailing the problem would "allow someone, especially a sophisticated criminal gang with the right tools, to break the security and steal a car,"

https://www.theguardian.com/technology/2013/jul/26/scientist-banned-revealing-codes-cars

After you’ve accepted that there will always be bugs the released products your next sane thing is to setup a process and workflow for identifying and resolving bugs. It’s just crazy how many software companies out there try to hide their bugs or try their best to make it difficult for people to report them. There are literally hundreds of known cases where large companies tried to stop reporting bugs in their software - just making their users suffer even more.

This line of thinking is stupidity defined. You just cannot stop people from finding bugs. What you should do is make it easy for people to find them for you. Have easy ways for reporting such bugs - such as customer support emails that can easily turn into bug reports, a bug reporting page like Facebook’s Report a Bug feature.

On your development team’s side also have the tools for keeping track of all bugs that are being reported - both by customers and your QA teams. Tools such as Jira are absolutely essential, just as important as the software development tools or issue trackers when the actual software was being developed.

Involve customers in the bug finding journey

This needs to be a management and marketing level decision - involve your customers in the bug finding process. Ask them for feedback, have formal ways of checking back for issues, reward them with freebies when they find bugs. Customers are the ideal QA of a software, they use it everyday and they use in ways that your dev team would not even think about using a software (e.g using MS Word for image editing or Power point to make web pages!).

Microsoft has a thing called bug bounty which literally inspires users to spend time to find bugs and be rewarded for such efforts. Google has it’s various reward programs for finding defects, these are all examples of far sighted companies who have not only accepted bugs in live products and made it easy to report - they are actively involving the customers in their journey to find and ultimately fix those bugs.

Have workflow for updating users about bugs

As you accept bugs as reality, your wording and communication will let your users also accept them and make them expect you to come up with fixes as soon as they are found. They also expect you to be mature about bugs found in the current system and have a place to know about such bugs and the status of those fixes. User forums are great for such things and modern ones like Zendesk or Uservoice and many others like them do a great job of updating users about bugs, getting their feedback and letting them know when things are fixed. They have also the feel of user communities and can lead to bigger and better things such as users helping each other out and users forming their own groups to teach each other.

Create a culture for celebrating finding and fixing bugs

Finally, the most important thing of all - within your company and your development team create a culture of celebrating the finding of each bug and fixing them. Some companies make the fatal mistake of making the dev team feel bad each time a bug is found - this creates the negative emotion that takes away the enthusiasm and spirit the team needs to polish off a released product over time. To a dev team the release product is their own creation - any bug would sound bad to them anyway, it defeats the purpose if the company culture is to make them feel worse. The culture should be that bugs are unfortunate yet inevitable - but once found how fast they are resolved and an updated software is released is the true sign of a great software company.

Trust me on this, after more than two decades in this bug creation, I mean software development business, this culture fix is the biggest thing that differentiates a great software company from the others.

Top Web Developer

How do you become a great web developer?

A question that we get often. Here’s our quick round up of the skills necessary to become a top web developer in Bangladesh (well anywhere, but we speak from the context of Bangladesh).

Foundation Coding Skills

As a professional web developer you will be learning many technologies and programming languages but some things are foundational. They are the absolute musts and you build everything off those. In other words you can never be a top web developer in Bangladesh or anywhere in the world without these coding skills:

HTML

The web is HTML. So you better be an expert of this. Simple.

Regardless of the platform, programming language, framework or library you use HTML is what you are going to work with on the user’s view (read interface, read front end) side.

HTML (HyperText Markup Language) is the standard markup language for creating websites, and HTML documents made with little sections that are marked by “tags”. Although there are close to a 100 official tags, you only need a few most of the time (here’s a great page that lists their top 10). Learn them and the rest you can just google whenever you are confused.

CSS

CSS or Cascading Style Sheets are the styling structure for all web pages. As such you can’t live without them. Every beautiful web page you see from Google to Facebook has CSS in the story. So you have to learn it. This is the 2nd area where you have to invest your energy well. The skills you learn on this investment will stay with you forever.

Great thing about CSS is that it saves you time. Things like CSS selector classes, can let you manage the style of multiple pages from just one place.

Just as HTML there’s a lot of CSS things to learn, but you can get away by learning the top ones and use Google for the rest of your web development career! Here’s a great list of must know CSS.

JavaScript

Javascript is a browser side computer language that makes web pages interactive. There are other languages that you’ll need for web application development, like PHP or C#, you’ll need to know them when you work on the back end but for front end Javascript is the only language that matters.

When you start learning a language like Javascript you start thinking like a programmer. This means that this is where you encounter algorithmic thinking, which is the bases for solving all the problems you will face as a programmer.

Tool Skills

Once you’ve mastered the foundational coding skill above learning the tools that you use is essential. The graphics here shows the most popular IDE (Integrated development environment) tools (source: Stack Overflow).

What you learn will depend very much on what code you are working on, so you don’t usually get much option there. But if you are learning on your own then you might use this to decide to pick up the tool that is most used. At the top of the list is Visual Studio. Makes sense as in the last couple of years, it is the tool that has made the most progress and is the most frequently updated. The number of extensions is growing and so is its community.

Code Versioning Skills

Code version control let’s you to track and maintain the code you work on. This is an absolute must skill for any web developer. Imagine a situation where you make a few small changes to your code and then the whole application stops working. It’s obvious that the changes you made has caused this and the fastest fix would be somehow to rollback to where you were. A version control system let’s you do just that. That is why it’s absolutely necessary.

Version control systems like GIT enable you to make mistakes without consequence. They are also necessary when you're cooperating with other web developers on the same code, they let you share code without worrying about breaking things.

Most popular versioning tools are GitHub, GitLab, MS Teams(TFS), Mercurial, etc. You should start with some flavor of Git as that has all the core concepts in place and it’s very likely you’ll end up working with a Git based system.

Graphic design Tools

In theory a web developer doesn’t really work on graphics - a designer does. But that’s just in theory. In reality you’ll find you have to dabble with graphics all the time. And if you don’t have some basic skills on graphics manipulation you’ll feel that you are getting stuck at every stage and waiting on someone to come and rescue you. Some popular tools for graphics include PhotoShop, Figma, Zeplin and Sketch know them a little bit at least by features and then try to learn at least one of them well.

Back-end and Databases Skills

Once you have mastered the part of the web site that the user sees the front-end, you have to move to the servers side - the back-end. On the server side you have the code and also the data storage - Database. The technology choice is massive here and you have to pick one or two focus on. The following graphs show the most popular languages (both desktop and web) and the most popular database technologies from the stackoverflow study. Use this to get an idea about what you should focus on if you have a choice.

Libraries and frameworks

Now that you have become used to the core skills for a web developer it’s time to focus on specialized libraries and frameworks. These make your life easy by doing all the hard lifting. With these libraries you can quickly get the basic structure of a web application up and running and then focus on adding features. This is a huge area by itself so I won’t go into the details but give you another graph of the most popular libraries out there currently. Know that no one actually learns all the libraries, you’ll focus on one or maybe two that you become real master of. The rest will only be used if you absolutely need to for a project.

Deployment and Hosting Skills

Now that you have made an interactive stylish web site, using HTML, CSS and JavaScript with a server side technology you love and a great database to store your data but how do you make it available to everyone on the internet? You’ll need to deploy it on a server and host it. Web hosting let’s you to store your resources (HTML files, CSS file, JS files, images, database) on a server that has internet connectivity and is accessible to everyone with a browser and an internet connection.

There are thousands hosting providers out there, learn the name of some good ones. Compare them and know their features. The other things you’ll need to know is how to get a domain for your app, how to point that domain to your website.

Software beyond the pandemic: The Rise of the Online Explorers

This infernal COVID 19 pandemic isn’t going away so easy - we just have accept this fact and move forward. Moving forward means - adapting. We are all adapting. Most companies in the world has adapted to the concept of work from home. It felt like a very difficult task, specially for the industries that were not IT driven, but as with any new concept - once the wrinkles has been ironed out it’s working out fine. In every industry, in every country in the world people are coming up with innovative solutions of adapting their work and life around the facts of social distancing and lock down. Software world is probably the most prepared for that adaptation, we after all are the facilitators for most of the adaptation with technologies like online conferencing, project management, file sharing, come to think of it, online (and offline) everything! But beyond the facilitation and the continuation of the old paradigms we also have to start thinking of how the world will change, how the new world beyond the pandemic (yes there will end to this someday, there has always been one, even black death) will change it’s behavior for consumption, software usage and living it’s life.

We don’t know. We can only predict. But what we know for sure is that there will be many permanent change to how we lead our lives. And as the leaders of change, us software people have to come up with new ways of doing things.

Online concerts and events

Here’s one change that has already started: online experiences for what used to be face to face events. With the lock down in place events like stand up comedy, football games or concerts can’t take place anymore. The alternative is to have them online of course. And we see that happening in many platforms. A great starter event for this new way of doing things came when the greats like Lady Gaga, Stevie Wonder, Shahrukh Khan, and many others came together to support the WHO with an online streamed show recently that raised almost $128 million for the COVID-19 Solidarity Response Fund, as well as local charities that are fighting the coronavirus.  

This overall movement towards online events is a natural progression from where we where before the pandemic. The virus only pushed us more and accelerated us in this direction. What is more interesting is:

“Will this become the new normal beyond the pandemic?”

I would argue yes. The pandemic will change our mindset about online entertainment, it is giving us a taste of the ease of online live streamed events and we like what we taste. On top of this our habit in consuming such events over prolonged time of the social distancing along with residual fear that will likely to remain for a while after the dust has settled will cement the success of these online experiences.

In line with that thinking online venues (the alternate of concert houses and stadiums) are coming up everywhere. Facebook pages like the billboard are picking up huge views. Pickathon launched the series "A Concert A Day" on April 8, which raises money for the MusiCares COVID-19 Relief Fund. Every day through June 7, at 1 pm PST and 4 pm EST, a new performance will be premiered or livestreamed via the Recording Academy's Facebook page, Amazon Music's Twitch channel, and Pickathon's YouTube channel. Featured artists include Margo Price, Mac DeMarco, Tyler Childers, and Foxygen. This is just the beginning.

Beyond online concerts

The interesting trend is that the online experience is going far beyond the old concerts and event streaming that we were used to in the good old days of pre-pandemic world (aka ancient times of 2019). Airbnb for example has focused on hosting “online experiences” as an alternative to their hosting your house for strangers mode. In their words:

These online experiences are as varied as their hosts are imaginative. You can cook with a family from Morocco or go out with someone and check out how the dogs are doing in the post nuclear accident Chernobyl.

This is the face of the new online exploration. This is just the beginning. There is so much more that can happen in this space that is unexplored. Take trips to interesting places for example. The obvious space for that is arm chair based world travelers who asks local experts to visit places they want to see, look at things they want to look. This already existed with 3D videos (and VR apps) like visiting Angkor Wat virtually or Vineyards but the post pandemic world will likely see an explosion of interest for such online explorations.

VR and AR technologies will need to catch up with human expectation for such online experiences. So that is the new horizon for hardware improvements for sure. Again it was going that way anyway, but the pandemic just pushed it harder and the demand for this will be much more stronger than the lukewarm early adopter space it was hovering around in.

Looking forward to that brave new world of online explorations. Life will be interesting. One little pesky virus will not put the spirit of human exploration down for sure. We are working on it but stay safe for now though :)

How to manage difficult software developers?

Software developers have a reputations for being “difficult”. But from my years of working with literally hundreds of developers I know that what is considered “difficult” is just a wrong way of looking at things. You can completely change the interaction and behavior of a “difficult” developer if you just adopt a few easy changes in your thinking and action. These “software people skills” are super easy and it’s really painful to see how many project managers or team leads don’t these. I’m going to do a series of software people skill going over them one by one. These are skills that are extremely easy to learn yet effective right away.

Instead of my usual of just listing them out, I’m going to make this series more hands on. I’m going to pickup pieces of conversation that are common between a manager and the “difficult” developer to show you the scenario and show you how you can completely change that conversation. You’ll notice that the manager will always be reasonable in his requests in the scenarios I talk about since I’m not talking about irrational or abusive interactions.

OK, to my skill #1

Software people skill #1: Always criticize code in private

Scene: Mr. Dev is in front of the his computer, Mr. Manager is standing next to him staring at the computer and speaking while pointing to the code. The last build of the product had some major bugs, most of the bugs on Mr. Dev’s area. Mr. Manger wants them fixed quickly so that they can meet the deadline (and also wants to air out his anger for the bugs hoping that the anger will make Mr. Dev create less bugs next time round). Other developers are within earshot.

Mr. Manager: Hey, there are way too many bugs in your part in this build. Can you please fix them asap so that we make the deadline?

Mr. Dev: You cannot blame it on me, I had way too many tasks, I told you they were impossible to finish and you are now seeing the result. So it’s your fault not mine and I’m not cleaning up your mess.

The mistake: Code is a developer’s craft. It is his creation, almost like his child and he will always identify with it. There is no way you can criticize his code and not get him emotionally affected and be defensive. And if you criticize in front of his peers and with his creation right in front of the conversation it is the worst you can make things for her. This will get you nowhere and will only make things worse down the line.

The solution: Know the sensitivity about criticizing a developer’s code. But that doesn’t mean you should not criticize or not take any action in the hope it will be sorted somehow. You just have to do it with some care.

• Make sure you have the discussion in a private space away from the peers of the developers. Ideally your office or a meeting space with the door closed. The developer will appreciate your care about keeping it private and also feel the importance of the need to address the issue.

• If the developer’s room is itself private, you should do the conversation away from his computer. This is purely from experience and a bit weird but there is definitely a psychological effect of receiving criticism right in front of the code that is being criticized.

• You should use inclusive language like “we” “us” rather than direct “you”. This gives the developer some relief that he is not the only one involved - because in a lot of situation he feels (and he might be right) that he was not the cause for the failure. Inclusive language moves the interaction to a feeling of working together to fix the issue.

• Softening the accusation a bit may help. This is case sensitive but the fact of live in software development is that people will make mistakes, there will always be some use case not thought out, some requirements will always be vague, etc. So once again if the language feels like you understand the complicated nature of a developer’s job, his reality of dealing with all kinds of unknowns and variables of a project, he will feel more understood and be less defensive.