When and How to Modernize Legacy Systems

Jack be nimble...

Jack be quick …

If 2020 taught us anything, it’s that being nimble is everything. And in today’s ever-fluctuating business climate, if you can’t be agile and change course quickly, you most definitely will get burned.

But how can you pivot and adapt quickly when your systems are outdated? The answer is: you sometimes can, but it’s a heck of a lot slower and tougher. And in this state of constant flux we’re living in, inefficiency and lag can be the death of a business.

But, we get it. Thinking about replacing existing systems or creating new integrations can feel overwhelming or even downright impossible. There’s disruption to consider, staff training, and budget, just to name a few concerns that go along with a big change like this. Often the pain of not evolving has to get worse than the pain of sticking with an outdated system for changes to be made. But waiting to the point of crisis often means bleeding time and money for way longer than necessary.

Is it Time? Symptoms of a Legacy System

One of the most common questions we get is whether a system overhaul is really needed. And even though we’re dev nerds who love building new things, we don’t hesitate to tell clients if the time’s not right for them to upgrade.

If you find yourself stuck in the should-we-should-we-not rut, here are some common indicators a change might be needed:

1. Are you seeing speed issues?
2. Do security or compliance issues keep cropping up?
3. Is your team disengaged due to system issues?
4. Are you getting the metrics you need?
5. Is your system functional but not scalable?
6. What’s the key business value and is it being accomplished well?
7. Are you finding your system to be more and more unpredictable or unreliable?
8. Can it handle the needed data formats?
9. Is output going down?
10. Are frustrations going up?

A Thoughtful Approach to System Upgrades

Sometimes a good ol’ fashioned pro and con list can help make system replacement issues easier. While it’s not always that simplistic, we love sitting down with clients and wading through the good, the bad, and often the ugly related to system needs and how they fit into overall business goals.

Here are a few topics we hash out with clients all the time as system decisions get made:

Replacing vs Bandaiding

You’ve probably sat in those meetings where the groans start as it’s decided the company needs to limp along further with an under-functioning system. Sure, from an immediate budget standpoint it might seem to make the most sense. And in some situations, you really can stick with an existing system and just make some process changes or add a few bandaid fixes to extend its life. But oftentimes, staying the course with an outdated system means way more trouble than it’s worth.

Certainly making the decision to implement a new system or to create some integrations that will help isn’t easy. And it can be super helpful to have an outside source weigh in. Sometimes you’re just too “in it” to see the best course of action. And often the solution isn’t black and white. That’s where having a third party to guide you into asking the right questions and diving deep alongside you can help.

Phased Implementation

Doing an all-at-once system replacement might sound sexy, but it’s not always wise. New systems can often be built in parts and pieces over time and sometimes even off-the-shelf products can be incorporated to ease costs. We walk our clients through the pros and cons of going “big bang,” as we like to call it, and brainstorm different implementation scenarios to determine what’s best.

Often a phased rollout makes the most sense. Not only can this be a budget-friendly option, but it allows you to swap out different parts of the system a bit at a time, allowing for testing and feedback from internal teams and users as things unfold.

Testing Early and Often

While it requires some upfront work, testing regularly (and with the right folks) can save you significant time and money in the long run. And it’s critical to get holistic feedback from different audiences, especially end users. So often development teams and others who are deep in the trenches miss glaring issues and opportunities that end users can spot in a moment. Thorough testing means not only catching potential problems but creating a better user experience, too.

Maybe there’s a new feature your team hasn’t thought of but end users are craving. Or perhaps there’s a common user workaround going on (e.g. repurposing a field) that could trip up data migration. Gathering input from those who use your system day in and day out means fewer surprises and maximized ROI.

Other things to consider:

• How is the new system going to change your business processes? Or should it be built to accommodate current processes?
• What’s the plan for reverting back if issues arise?
• How do you maintain the highest system security?
• What team training will need to happen?
• How can disruption be minimized?
• Will the new tech be easy for your developers to run with?
• How will a new system play with the tech you’re keeping?
• How do you teach customers to adopt new systems and features?
• When you develop a new system, are you porting over every feature?
• What can be done to ease the transition for everyone involved?

These are the kinds of questions that keep our clients up at night. But they’re questions that get us all kinds of giddy when working through. Because at the end of the day, we don’t see ourselves as product-builders but problem solvers. Putting our heads together with clients—instead of just dictating what we think should happen—means an all-around better result (and a heck of a lot more fun).

If we had to give you just one piece of advice on legacy systems, it would be this: the most seamless and successful transitions are a result of solid planning. Know what you’ve got. Understand thoroughly what’s working for you and your customers and what’s not. Engage experts to help you make good decisions if you can. Have a plan for where you want to go, while staying flexible as you test and tweak along the way.

The difference between a website and a microsite is primarily a matter of marketing strategy. A company’s main website is the hub of its online presence, the place where potential customers visit to learn more, where potential employees start their research on the brand. So what is the purpose of a microsite? A microsite isn’t a full statement of a company’s values and services, but rather focused on a specific product, event, or service. A microsite is still a website, but there are key differences in when you would use a microsite and how to create a microsite. The content of the site may also differ from the parent company’s brand standards, messaging, voice, and tone.

So when should you choose a microsite over a website? Here are 5 factors to consider as you plan a marketing or web development project that harnesses the power of a microsite.

Microsite Design is Flashier

The purpose of a microsite is to draw a high volume of attention to a new product, spin-up, or upcoming event. This is why they are often more interactive and visually complex than a company’s brochure website.

What is a microsite example? Browse the microsites on Hubspot’s most ingenious microsites list to see several examples of the features that make microsites stand out. Countdown clocks, interactive test drives and tours, or the chance to immediately create a GIF or social media post are some of the calls to action a user might encounter on a microsite. These features are all part of the marketing strategy to build excitement and buzz about the subject of the microsite.

A website, on the other hand, is more likely to lead with a values-forward statement or an image--like the cover of a brochure. Even when interactive elements are present, it’s probable that they will be more about introducing the company, and less about an immediate call to action.

Microsites Are Time-Sensitive

One of the reasons calls to action are such an important part of a microsite is these sites are time-sensitive. Whether you’re driving event signups or boosting the signal of a new product, the launch strategy won’t last forever. But that doesn’t mean the microsite has to go away as the marketing strategy evolves. The microsite can exist for as long as it needs to, and there isn’t one defined best practice.

A website, on the other hand, is part of a brand’s authority and is largely permanent. Though the design, content, and structure might change with the times, the website remains. In fact, if a company’s main website disappears, it might cause concern among customers or affiliates—not to mention employees.

Microsites Have Independent Domains

You might wonder, what is the value of creating a distinct microsite versus a landing page or other content on the main website? When it comes to microsite vs landing page, there are several factors to consider.

Firstly, a microsite can be larger than just one page. Many include a collection of pages, allowing users their own unique experience of this event or product. The ability to have a unique, fully-independent domain means the microsite can be divorced from other perceptions of the brand completely. With a landing page or content on the main website, that would not be possible.

Another benefit of a microsite is that it allows flexibility with the launch of new products or services. If you integrate information about this offering into your main website, then remove it later, this could give a perception of failure or weakness. With a microsite, on the other hand, the site can just be taken down without any reflection on the parent company whatsoever.

Another value of an independent microsite is the ability to experiment with domain extensions that may appeal more to your target audience. This includes everything from the ubiquitous “.com” to trendy new options like “.life” or “.app”. Just remember that some demographics may be less familiar with newer extensions—you don’t want your hard-built microsite to be suspected as spam. When in doubt, stick with what you know.

Microsites Must Be Highly Performant

What makes a good microsite? One of the most essential elements is performance.

Every website on the Internet today is expected to be performant. 1 in 4 people will abandon a website that takes longer than four seconds to load. Microsites must go beyond customer expectations in this regard if the marketing strategy is to be successful. With a powerful strategy behind it, the microsite might be attracting lots more traffic at once. Plus, the site itself is equipped with all the animated and interactive features that provide the payoff for the visitors. If these features don’t load with the same speed, quality, and efficiency for every user, a large part of the attention for the microsite will fade before those interested people can become customers. This is why we believe a microsite should load in a tenth of a second or less, an outcome that depends on microsite architecture.

Performance doesn’t just include speed, but also functionality across a wide variety of devices. From multiple models of mobile phone, to laptops, desktops, tablets, and even other smart devices, the content of the microsite needs to translate well across all platforms and operating systems.

Microsites Aren’t Necessarily Easier

There might be an expectation that because a microsite contains fewer pages and is more focused in scope than a website, it will be easier to build or maintain. But the time to complete each actually depends on the functionality. Since the content of a brochure website is historically more static, it might be easier to implement. A microsite with complex functionality and animation might be more intensive to create, especially with concerns around load time efficiency and performance to consider.

---

Though microsites and websites are used for different purposes, users on the web don’t know whether they are visiting one or the other. They just want information, and to be engaged and excited by the content they find. At DeveloperTown, we collaborate with marketing teams to understand what features of either type of site will achieve your goals. Contact us to discuss upgrading your web presence.

In today’s fast-paced software world, the best developers know that standing still is the same as being left behind. Not only are there new breakthroughs and advancements made every day, clients are expecting more than ever; a recent study found that the number one problem for software development teams is capacity, and meeting the tough deadlines and backlogs for delivering projects.

Whether you’re working on a team or on a solo project, it is in your best interest to elevate your game. Getting better as a software developer is about keeping your focus divided up between the forward-facing tech trends that drive the industry, the best practices of your fellow programmers around you, and honest self-analysis to understand your areas for improvement.

Here are three tips on how to get better at software development and areas of growth for software development.

#1 Agnostic Language Development

The ultimate goal for any software developer should be to achieve language agnosticism. For some time, it was considered fine to be proficient in simply one language, or to have that language be your area of expertise. This has also become the case for many development teams, as we’ve gotten used to the idea of saying, “We are a Java team.” That meant whatever engineering problem gets presented to the team, the answer will undoubtedly be written in Java.

But, what if the issue could be more accurately or efficiently solved using Ruby on Rails, or PHP? If programming is about working smarter, and not harder, then language agnosticism is your only hope. When you’re able to stop thinking in ultra-specific terms, it becomes easier to get creative and use your natural intuition to guide you. That’s a big part of what the most advanced software developers do: they learn enough theory to forget about the rules.

That being said, it’s not exactly reasonable to expect developers to gain overnight mastery of the 700 programming languages used today. This is even more true for young engineers, many of whom may be in their first jobs and trying to make a name for themselves by plowing through assignments. So, in the same vein of working smarter, a good approach may be to choose an area of work that appeals to you, and focus on the languages most used there. For instance, if embedded systems are calling to you, try knocking out all the lower-level languages like C++ and its offshoots. If instead a data-driven application development career is appealing, you might split things between front and back-end languages. Once you’ve gotten those down, any engineering problem in that area will be open for you to think about from an agnostic standpoint.

#2 How to Improve as a Software Developer Through Collaboration

All too often, we think of software development as being a solitary experience. And, to some effect, it’s not without its truth. The coding aspect often consists of staring into our screens, tightening and revising strings, checking for errors, and eventually starting all over again. But in reality, this is only a part of our day. Studies have shown that programmers only spend 32% of their time building or maintaining code; the rest is spent within collaborative spaces. We meet for SCRUM or a daily stand-up, we sit down with clients and management; we even go out to lunch and attend coder meet-ups. Why? Because we’re able to motivate and inspire one another, even if it happens while arguing over tabs and spaces.

Collaboration is one of the top skills for developers. breeds a greater understanding of difficult or obtuse concepts. Nowhere is this more true than when working on open source projects. Sites like GitHub offer programmers everywhere the chance to work on cool and interesting projects with other developers from all around the world. That means as you’re contributing, you’re gaining access to different perspectives all on the same problem.You may be amazed to see one individual using a certain language or approach you wouldn’t ever conceive of using for a particular block. Or, perhaps, they’re using a new language that while you’re aware of, you still don’t have a firm grasp on its real-world applications. This experience helps to ground those abstract concepts, resulting in a valuable learning experience that doesn’t feel too formal or like a pop quiz.

Additionally, open source projects can be a huge boost for young developers just starting out. While you may not have the longest resume in employment, this kind of open source work experience can still be quite impressive. It also provides a kind of portfolio for your work. Whereas employers code is proprietary, hiring managers can just check out your GitHub and see what kind of great work you really do. And, let’s be honest, isn’t improving as a software developer kind of all about stepping up in employment?

#3 Why Reading Books Isn’t Retro for Developers

Let’s be frank: coding is complicated. Maybe not for the reasons that non-technical people think, but the concepts that float around this planet like satellites are many and were created by some of the most brilliant computer minds we’ve ever known. In addition, those concepts often intertwine and connect, meaning it may be impossible to understand one without the other. So, if we’re looking to truly elevate and become more masterful in our programming ways, we need to dedicate real and measurable time to being a student on the subject.

There are a number of hugely influential and impactful books written on the topic of software development. Some may wonder why these lessons can’t simply be distilled into Power Points, or why they can’t Google something or check out StackOverflow for answers.And in some ways, they can with these websites to improve coding skills. But there is sometimes a bit of a, let’s say “ego problem” when it comes to coders. Not knowing the answer to something is frustrating and they want to wipe that problem out immediately to get back on track with their quest for perfection. Reading a lengthy book is a more passive experience. There’s no jumping to a highlighted section, or searching within a document to find the exact information you need; instead, you relinquish control to the writer, allowing them to guide you through those high-level concepts and provide context for each one. The result is a more thorough and complete understanding of ideas related to development.

A couple of books on the subject of personal development are:

• Clean Code
• The Pragmatic Programmer
• The Mythical Man Month

Regardless of your professional goals or eventual career path, keep in mind that getting better isn’t about competition or measuring sticks. Too often we compare ourselves to others as a substitute for using a mirror. Instead, think of your efforts to elevate your game as being about self-love and self-care.

What Are the Three Approaches of Digital Transformation?

Businesses exploring a digital transformation strategy are often looking for a tried-and-tested route to success. In a 2016 report on digital transformation by McKinsey
reported that 70% or more of these complex modernization programs don’t achieve their goals. Walking into a minefield, it makes sense that you want to look at a map to see where others have been caught up, or worse.

To provide a scaffold for planning, the digital modernization process is often broken down into three essential components: process, operations, and customer relationships.

The digital transformation team at DeveloperTown believes this is helpful, but thinking about these as separate can also create barriers to achieving all the goals of your project. Process is built into the operations and customer relationships at your business. In fact, it’s how those aspects succeed! And, any overhaul to your operations or customer service will require a change in processes. That’s how they transform!

Making changes easy to manage, implement, and measure is the real work of successful digital transformation. Here are some data points and strategic insights to help you plan the upgrades that will help your business succeed and grow.

What is an Example of Digital Transformation?

Today, digital transformation is achieved through cutting-edge technologies like data analytics, automation, or artificial intelligence. By eliminating or simplifying time-consuming manual processes, businesses achieve more efficiency. Whether it’s making a dollar go further or allowing talented employees more room in their schedules, digital transformation eliminates the unnecessary and expands the horizons of what’s possible by including technology in all aspects of the business.

Automating processes like payroll or using analytics to uncover gaps doesn’t just mean a practical change in the day-to-day work. These new processes also generate a massive cultural shift that every individual must accept. At times, we’ve seen some of the biggest barriers to the success of modernization projects can be employees who aren’t open to the change.

However, according to recent digital transformation statistics, 2020 might be the year that has ended this change resistance for many employees. As working from home during social distancing has become essential for many employees, digital tools have become less foreign and more celebrated. Digital transformation spending has grown by 4-9% across every industry in 2020. Companies are prioritizing technology that helps them enable worker productivity, makes actionable data available faster, and meets customer expectations of online experience.

Who Leads Digital Transformation?

At most companies today, the Chief Information Officer (CIO) is usually in charge of digital transformation initiatives. This means everything from data protection to IT requirements to the change management strategy. However, this centralization of responsibility can be one of the biggest drivers of project failure. Eight in ten digital transformations involve multiple functions or business units. Unless the CIO has an in-depth understanding of each of these entities, they don’t know what they don’t know—and that can catch their whole company unawares.

That’s why many companies have started to engage the entire C-Suite in digital transformation visioning and storytelling, with the need for a sense of urgency around the change conveyed to middle management and on down the chain of command until every employee understands the how and why of the transformation plan. While it’s important to agree who is leading the decision making, it’s equally important to be sure everyone follows—and that they know where this journey is headed.

Digital Transformation Guide for Operations

Using digital tools to improve operations should start with a careful understanding of the current systems. It might be tempting to pursue automating an entire process like payroll or onboarding, but these sweeping measures can create unanticipated issues if it’s not understood how everything integrates.

Plus, why think so basic? Technology like artificial intelligence and advanced analytics didn’t exist a decade ago when digital transformations started. Now, these innovations represent the opportunity to replace more than one step within a series, with human intervention at key stages to check the work or carry out more complex tasks.

Tracking, reporting, and regulatory compliance are some of the operations elements that are usually first on the list for transformation when we are called on to help a business. But through careful listening and fact finding, DeveloperTown often finds more complex opportunities that will continue to transform the business into the future. Think about it: do you want to go through this again in a few short years?

Here are some of the elements to consider as you plan digital transformation to operations processes:

• How will you invest in training, hiring, and infrastructure for the new technology, as well as to support the growth you anticipate?
• What functional siloes between departments might lead to change resistance?
• What pain point does this technology address? Don’t implement technology just for the sake of doing so.
• What skill gaps and technical capabilities is your team missing that you will need to carry out the project?

It’s also worth noting that companies who try to carry out operations transformation step-by-step routinely see projects stall or fail. According to Gartner, these organizations only report an average of 16% process toward their goals, despite having worked on the project for 12 months. That means when it’s time to change, just go for it!

Digital Transformation Services for Customer Relationships

Digital transformation is essential to improve customer relationships because today’s customers expect digital experiences. Today, even high-trust customer needs like finance management, legal processes, or shopping for a home, car, or appliance are increasingly trusted to technology.

To transform customer interactions for high-trust industries like finance, retail, and healthcare, it helps to examine why customers trust the in-person process to begin with. Taking out a mortgage, shopping for a car, or getting a medical diagnosis is a big event, something we trust more due to the in-person interactions that come with it. Learning to digitize these experiences in a way that still builds trust is defining the most successful digital transformations today.

Digital transformation doesn’t just apply to the customer’s transaction, but also how they are served after they make a purchase. Have you ever been frustrated calling customer service and having to tell the same story three times? Or waited all day for a repair person who you couldn’t track or follow up with? These negative customer experiences can be addressed through technology in a way that meets the customer’s needs without causing the business to incur more expenses.

When deciding the vision for your digital customer service transformation, consider these data points from Salesforce:

• 66% of customers are likely to switch brands if they feel treated like a number, not an individual.
• 64% of general consumers and 80% of business buyers expect real-time interaction from brands.
• 73% of customers would prefer products that self-diagnose issues and order replacement parts or service automatically.

Customer relationships have moved beyond the transaction into a need for customer engagement. Tools like marketing automation for social media and email, chatbots, recommended related products, and augmented reality help businesses attract new customers and retain existing ones. Choosing the right ones to invest in for your audiences can give you the competitive edge.

Successful Digital Transformation Case Studies

All this talk of digital transformation might give you a better idea of the opportunities, but your business still needs to answer a very practical question: What is included in digital transformation? The answer for you won’t necessarily look like the answer for anyone else in your industry. Here are some case studies of digital transformation that make the abstract more practical.

Republic Airways
needed to improve the quality of life for their crew so they could retain top talent. Over 200 hours of interviews helped them leverage technology that not only improved employee experience, but also made information exchange easier and tracked compliance information.

Tenant Tracker
came into existence when a commercial real estate property manager needed a tool to simply tenant coordination and track documentation. Moving data into the cloud resulted in a mobile option that makes life better for property owners and tenants alike.

Bass Educational Services was created to help students with learning differences connect to the best college experiences for their needs and goals. Leveraging the data collected by the company’s founder led to the creation of the CollegeWebLD app, a tool for students across the US.

These examples of digital transformation represent how a manual process can become more efficient and widely available due to technology. But we’re also proud that they represent the DeveloperTown philosophy of listening-first to employ the best approach possible. Since we know both startups and big business, we bring a broad look at opportunities to the table. We don’t just look at your competitors or rely on a template like a digital transformation pdf. We look beyond what exists around you to see what’s possible and how all opportunities can be leveraged to transform not just your business, but your industry.

Create Confident Digital Transformation with DeveloperTown

Trying to plan your digital transformation? Or facing a stalled IT project you aren’t sure how to jump start? DeveloperTown is the team with the passion, compassion, and talent to help you achieve goals and maybe even find efficiencies you aren’t targeting. Contact us today and let’s transform the world.

Have you ever joined a project that was far behind schedule, significantly over budget, or seemed like it wasn’t making forward progress? If you’re in the world of software, odds are you have at one time or another.

If you find yourself on a rescue mission, know that you’re not alone in the struggle. Rescue projects are some of the most difficult projects to join. They also have the potential to be some of the most rewarding or beneficial to your company.

In the next few paragraphs, I’ll be sharing four bits of advice to consider when trying to get the project ship from sinking. Ready to get that ship back sailing? Let’s do this!

Gather as much information as you can about the project

After joining, it will quickly become apparent that there is confusion and disagreement about where and how to begin fixing things, what needs to be changed, what is the shortest path to delivering value, and even understanding the scope of what needs to be done. So how should a person or team approach a rescue project?

Read any and all documentation the project has generated. Go through every page on any project website, public facing or internal. Talk to project members to gather documentation locations as projects typically have multiple locations where documentation is located. Even if the documentation is old and known to be out-of-date, it still provides good context on project history.

When gathering information, keep in mind that there may be content that conflicts. As technology professionals, we value consistency and order and it may be frustrating to read conflicting content, especially if it’s unclear which is correct and/or up-to-date. Or maybe none of it is up-to-date. But keep in mind that all information about the project will provide either current state, previous state, or context about how the project has progressed. All this information will almost certainly be valuable at some point. Consider the last time you were in a meeting and someone brought up something you didn’t know existed on your own project. That’s expected in the beginning, but the sooner you can get past that stage the faster you’ll be able to be a valuable project resource.

Assess

Whether you’re just joining the project or you’ve been on the project for a while, take a step back and do an assessment. What are the strengths and weaknesses? What needs to be changed to result in the project delivering value faster? Are there any documents you think would be helpful but don’t exist? Take your own ego out of the equation. If you were in your client’s shoes, what would you expect or need?

Even if you haven’t been asked to write an assessment document, create one anyway. Write up a background of the project to date, list the current state, list any future state vision, and enumerate the goals of the project. Then start listing the changes you would make and the reasoning. Pay close attention to staying objective when suggesting changes. After you’ve been on the project four to eight weeks and have a fairly mature assessment document, share it with your fellow project members and ask for feedback and/or corrections. It may start a discussion about what changes need to be made.

While writing the assessment document, keep a list of documentation that doesn’t exist (or you just didn’t find yet) that would have helped you understand the project better. List in the assessment recommendations to create this documentation, which may help not only current project members but the next new project member get up to speed faster.

Projects are People

When talking about a rescue project, I’ve heard it said that “tech is easy.” It doesn't mean that fixing technical issues is always easy, but rather that fixing technical issues is easier than fixing team issues. Projects are collections of people who work together to accomplish a goal. By definition, a rescue project usually consists of a team or team members that are not working as well together as they could to accomplish their goals.

Consider that, in small group communication, there are multiple phases the group must go through before it can work together effectively to accomplish goals. As new members join there will inevitably be a regression in the stages as new members assert themselves and the group adjusts to a different dynamic. Take this into consideration before making assumptions or assertions about past project members and roles.

If there is conflict then that means that not everyone agrees on what is best or the way to go about achieving shared goals, but don’t assume that project members are being difficult just for the sake of being difficult. At the end of the day, with very few exceptions, everyone is doing what they think is best for the project.

Change Takes Time

As motivated workers, we want to start fixing the project right away. We want to see our progress reflected in the timeline or the budget. We want to make a difference! But realistically change takes time. And the amount of time that takes has some relation to how long the project has been in existence. So don’t get discouraged when weeks or even months go by without seeing the change you think should happen, or even when you see what looks like a regression. Continue to work hard and put in your best effort. Often change comes suddenly and unexpectedly, so just when you think it’s never going to change may be right before you get surprised.

All Aboard

Rescue projects are some of the most challenging and rewarding projects one can be assigned. Whether you wanted to be assigned to the rescue project or not, approaching it with a positive attitude and coming prepared will lead to outcomes you can be proud of. And you never know, you just might help the project sail off into the sunset.

Philanthropy Driven Development

Bringing the strengths of the nonprofit sector to software development.

About a year ago, having spent the majority of my career studying and working in the nonprofit sector, I decided to take the plunge into the world of software development. With a year of experience in the tech space under my belt, I’ve found myself reflecting on all I’ve learned working in both sectors and what these two seemingly disparate worlds could teach the other.

To be a bit more specific, the primary driver of the nonprofit sector is philanthropic, mission-driven thinking. In practice, this way of thinking is all about channeling our noble, empathetic inclinations strategically to bring about a greater good. Philanthropy, at its best, directs us to recognize needs, uncover their source, define remedial actions, and get to work.

So what can this way of thinking offer the world of software development? Below are three primary ways tapping into the power of philanthropic thinking can drive development and bring a fresh perspective to your next project.

Empathetically Identifying Gaps

A primary goal of philanthropy is to account for the gaps where unmet needs are present in a unique context. In practice, both in a nonprofit and tech context, identifying gaps is often no small task, especially when we have become accustomed over time to tackling day-to-day operations in specific ways. In the words of Aristotle, to account for these gaps and address them “[T]o the right extent, at the right time, with the right motive, and in the right way,” is an elusive endeavor.

Philanthropy, or the love of mankind, is at the heart of successful innovation in technology, not just because charitable giving improves public perception, but because it provides a uniquely empathetic mindset, that when channeled strategically, can drive adoption and usability, which in turn drives bottomline results.

Consider, for example, how your users experience your product. How are you currently seeking to account for their contexts, backgrounds, affinities, joys, and frustrations? From the perspective of philanthropy, approaching customer experience philanthropically is an effective way to put yourself in their shoes; however, this should be done with an empathetic eye for even the most subtle gaps in their experience and a continually application of Aristotle’s four principles of addressing these gaps, namely, extent, timing, motivation, and approach.

Uncovering Needs at Their Source

As the old adage goes, “Give a man a fish and feed him for a day, but teach a man to fish and feed him for a lifetime.” Philanthropic thinking directs us to recognize needs and uncover their underlying sources. The primary goal of philanthropy from this perspective is to calibrate the trajectory of our actions to most effectively alleviate and bring about a better world.

Consider how many products have been developed over the years that overwhelmingly missed the mark. If you boil it down, these products have often failed because the perceived need was misaligned with actual need in the market. Blackberry phones is an often cited example that comes to mind.

Often needs we are quick to identify are merely symptoms of a larger issue. Steel Tycoon and philanthropist, Andrew Carnegie experienced this firsthand as a boy of humble origins living in Pittsburgh. Having been given access to the personal library of his employer as a young man, he attributed this opportunity for education, at least in part, to his success as a businessman and paid it forward by building free libraries. In essence, he recognized poverty as a symptom of lack of access to education and created a library system that still stands today helping address the source of this need.

In the tech space, philanthropic thinking, at its best, can help to bring alignment between perception and reality by fostering conversation with observation. The primary idea here is to channel philanthropy’s inherent empathy in market research to identify and inventory the needs your product seeks to address, and verifying the source of those needs through end user observation. It provides the opportunity to capture impact metrics, again, through conversation and observation for the sake of continual improvement.

Supporting Agile Team Dynamics

Finally, philanthropic thinking provides the framework for building healthy and effective team dynamics and ungirds the servant leadership mentality essential to an Agile development context.

Philanthropy, as a discipline, is all about recognizing the best in ourselves and leveraging those strengths for the good mankind. In an Agile context, a philanthropic mentality is at the heart of generous ideation, iterative development, conversation, sustainability, interdepartmental collaboration, and embracing change as it opens us up to being part of something bigger than ourselves.

We part a great deal of emphasis on being iterative in our development, but often spend little time being iterative with our mindset. So as you approach your next project, consider what philanthropically driven development can offer you and your team. Take some time to consider what gaps may not yet be identified, seek out the source of the need you are seeking to address, and bring inspiration to your team.

How'd we get here?

In the 2019 not-so-official state of Javascript report, I heard the undertones of anguish and grumbling towards the javascript ecosystem, but whats new right? People have been complaining about Javascript since its three week incubation and subsequent birth. For good reason.

Example, executing random type additions:

> "" + {}
> "[object Object]"
> {} + ""
> 0

But…somehow, through all the pain and chaos, we have come together as a community and have made this language somewhat bearable to work with.

In 2012, Typescript was born and all of a sudden you could add Types!.to!.Javascript! as ForSortaRealNow.

In 2015 there were whispers of something called the webpack and react and all you had to was provide a small sacrificial offering, followed by installing the universe of npm modules to use them. Only then, would you be on your merry way.

In 2016, 2017, 2018, and 2019 if you updated a package and something broke, there was usually at least one GitHub issue that would say something nonchalantly like “Breaking change, no take backs”, and then go on to explain why you would be spending the next three days upgrading all your dependencies and refactoring your whole application. By the way, if this was you, I personally want to say “You’re a hero”.

Jokes aside, 2015-present has really been a journey of intense growing pain, but I personally believe we are on the brink of a new era of Javasc–cough Typescript. Yarn V2 just came out, and I am seriously more pumped about the ecosystem than ever. I would put this change on the same level of importance as the move to ECMAScript 6. Yep I said it. Let me explain why.

Yarn V2

Workspaces

Workspaces were a concept in V1 of Yarn, they should be thought of like a module. You .NET devs can think of them like a project within a solution. They are a good solution for a monorepo, but in V1, a lot was left up to the developer to get all their dev tools (Typescript, Webpack, and VS Code, etc) all on the same page as to what was going on with those workspaces. I remember it took a week or two for me to just get file resolution sorted out between all of that, and I know for fact, that setup was custom…and not quite right. 🙂

After you have gone through the migration to yarn berry, you can set up a more realistic and safe monorepo without worrying (too much) about how those workspaces are going to get resolved. Workspace resolution is treated as a class one citizen now. It even has its own protocol.

Assume the following directory structure

root
 - packages
     - web
         - src
             - data
             - components
     - api
     - shared

To reference another workspace from the web workspace, use the workspace protocol . Example:

root/packages/web/package.json

"@repo/shared": "workspace:packages/shared"

example use:

import SomeSharedThing from "@repo/shared/SomeSharedThing"

Okay, but why was this a problem in V1 and why does it work better now?

Plug’n’Play, Plugins, and File/Module Resolution

The Problem: Resolvers.

Here is an excerpt from the yarn docs linked above that explains it well:

“Over the years that led to Plug’n’Play being designed and adopted as the main install strategy, various projects came up with their own implementation of the Node Resolution Algorithm - usually to circumvent shortcomings of the require.resolve API. Such projects can be Webpack (enhanced-resolve), Babel (resolve), Jest (jest-resolve), Metro (metro-resolver), …”

This means that if you wanted to combine and use different technologies that use different file/module resolving strategies, you would likely be dealing with configurations to make sure files are being resolved correctly.

But no more. No more tweaking aliases in configs. No more help from random third party resolvers, etc. No more.

The Solution: Plug,'n’Play(pnp.js)

Yarn V2 solves the file resolution issue through the use of the pnp.js file and their plugin strategy.

• They introduced the concept of the pnp.js file (If you have ever used webpack stats, it is similar to that). Basically it’s a file that declares explicitly what dependencies/workspaces depend on and where those packages are all the way down the dependency tree. It then during runtime(think webpacking) can intercept calls to modules, and provide a virtual link to where yarn is keeping those modules now which by default are zipped within its cache folder. For developer tools like eslint, typescript and vs-code they wrote a pnpify module that basically fakes the existence of the node_modules folder for the same purpose. This is temporary until those tools can support pnp out of the box.
• Yarn V2 is built primarily using a plugin strategy. Things like commands are even plugins(e.g yarn add). Along with commands, they have also built plugins to wrap how files get resolved from different mainstream file resolvers.

Together with the pnp.js file, and plugins, they can look to see what module resolution a package depends on (via the dependency tree) and then tell Node exactly where to find that module/package.

Zero Installs

Yarn berry has some great documentation around this topic. Zero installs is not a feature specific to yarn berry, but it is by far more possible because of it. Since, node_modules are no longer a thing, and instead the yarn cache is maintained through compressed .zip files, It is much more feasible to commit these to your repository. Zero installs is configured purely through .gitignore. You can choose to do so or not. Read more about it here.

I have decided to jump aboard, and have not regretted it one bit. It improves workflow all over the place, specifically around switching branches during the PR process and the build process itself.

Constraints

Yarn 2 has the option to provide constraints. Constraints are rules about your dependencies. Yarn has defined a few of their own constraints, but you can also create your own.

The yarn maintainers are using a programming language called Prolog to create these constraints. Prolog is a fact based engine. Think of it as a database of facts that we can query against and determine if something is true or not.

From what I understand…upon running yarn constraints yarn berry generates a database of facts using the projects workspaces, and dependencyTypes(dependencies, devDependencies, etc) and in plain english those sound something like

“fact: the workspace someWorkspaceName depends on Lodash version 4.4.2 in devDependencies” -yarn docs.

Then it gobbles that list of DB facts, the predefined rules yarn has provided, and the source file the end user provides for custom constraints(constraints.pro by default). After that it loops over a list of query results provided by tauProlog’s(JS wrapper around prolog) query method and generates an array of enforced Dependencies.

Now constraints like Uncle Bobs dependency rule are much more possible and more importantly, enforceable.

This rule says that: “source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.” - Uncle Bob

Constraints are still in newborn status, but I plan on using them.

To wrap up. I have a lot of hope for Yarn v2. The lead maintainer @arcanis is someone I have come to respect, and is someone who not only sees the issues of the JS ecosystem, but has solved those problems. IMO, Yarn V2 is the future of the JS/TS ecosystem. At least until Deno takes over.

I think it’s reasonably safe to say that when I first started at DeveloperTown in 2014 I was not expecting the following two things to become a reality: that I’d last in a software development consulting firm with no software development knowledge and that I’d eventually write a blog post about leadership in the midst of a global pandemic.

Both are true at the moment. I’ve come quite a ways from being clueless about what an API was or in the dark about things such as pull requests. (Quite naturally, as a 16 year old boy stuck in a now 33 year old’s body, I assumed a PR had to do with a rather gaseous bodily function and my index finger.)

But here we are. Slightly more knowledgeable about software and spending most of my time indoors as our brave medical men and women, delivery drivers, teachers, grocery store clerks, and city employees are on the front lines. It’s a scary time. A time where I often wonder what should we be doing? Who is going to stand up and lead? How should they be doing it? And what about us that are not guaranteed a future? What about our jobs? How are we going to make it?

These questions are undoubtedly floating through your head and the head of your bosses, coworkers, and employees.

And if you find yourself in a place of leadership, now is the time to answer those questions.

One of the many reasons I’ve stuck around at DeveloperTown is the fact that we have strong leaders. Leaders who are trying to answer those questions. Leaders who I trust will do the right thing, not only for the business but for their employees as well.

But what does the right thing look like now? I have a few suggestions that come straight from the DT leadership playbook.

1. As a leader, it’s more important than ever to communicate with honesty and empathy. People are going to create their own narratives if they don’t hear one from you. They may even create one if you share the truth over and over. But they deserve to know where the business stands and where you see it going. If you don’t know, that's okay too. Tell them what you do know. No sugar coating, no false hope, no unneeded dread.
2. The best way to reduce anxiety is to start thinking about what your organization can do for others. How are your clients feeling at this time? Serve them with grace and care. Demonstrate this to your team. Vocalize it over and over. There’s never been a better time to revisit your mission statement and remind yourself and your team that now is the time to serve others. It’s really hard to worry about yourself while you’re helping someone else.
3. Samuel Johnson was quoted as saying, “People need to be reminded more than they need to be instructed.” I happen to agree with him. Set up recurring touchpoints with your team to celebrate their wins and check in. Be available. A great example of this would be a now weekly virtual coffee social via Google Hangouts at DeveloperTown. An employee put it together and it’s been a highlight of this time in quarantine. It’s a weekly reminder that we’re in this together...and that some of us have very fun coffee mugs.

Leadership in the time of COVID-19 doesn’t have to mean a monumental, solo effort for only those at the top. But for those who find themselves in or identify with a leadership role, now is the time to communicate, serve others, and regularly remind our teams that we’re in this together.

When things get tough, it’s up to good people to stand up and do our part. Luckily, that means all of us get to help.

Even those of us who start blog posts with a fart joke.

With the unemployment rate hovering below 4% nationally, companies all over are fighting to snag the best candidates on the market. To win the talent war, you've got to get creative on how you attract the talent your business needs to grow and succeed. But how can recruiters and talent management folk do just that? Well have no fear. We’re going to cover a few different tactics you need to be using to make the recruiting process as efficient and painless as possible.

First, let’s talk communication. This sounds like a no-brainer but thorough communication and follow through can be your competitive advantage against your fellow recruiting peers. I can’t tell you how many times a candidate tells me about a bad experience they’ve had with a recruiter, and usually it's always focused around poor communication. From first look to first day, it’s imperative to set expectations as to how and when communication will occur. Sometimes, even text check-ins are sufficient, but whatever you and your candidate agree to, don’t let them fall into the forbidden resume black hole. Even if you simply check in to say that you don’t have an update, that will go a lot further than radio silence. It’s important to have empathy for your candidate, as you certainly wouldn’t want to be forgotten about.

Next, let’s discuss candidate applications. Majority of candidates are applying to jobs from their mobile devices. Have you taken the time to test your company’s career page and apply to an open role via mobile? How long does the process take? Are there tons of questions/forms needing to be filled out? If the mobile application process takes over two minutes, it’s time for a change. Once you’ve simplified the mobile application process, look at the job description you or the hiring manager has written. Essentially, candidates want to know three main items: an overview of the company (culture), an idea as to how they’ll impact the business and the expertise needed for the role. Provide four to five bullets per section, no more is needed. Ideally, you are trying to cast a wider net, and if you have an abundance of “requirements” even some of the most qualified applicants may not feel they’re qualified for the role, thus won’t apply at all.

Last, be ready to battle the dreaded counteroffer. Companies know how hard it is to find talent, and subsequently they don’t want to lose that talent. Educate your candidates on why accepting a counteroffer is never a good idea. I read a few years ago a study which said 80-90% of candidates who accept a counter offer from their employer end up leaving within the following twelve months. Currently, I’ve found money is not the most pressing factor for candidates to want to leave their organization. Career growth/opportunity and feeling of purpose are on the top of the list. Remind your candidates as to their motivating factors for wanting to leave, and why you started the conversation with them in the first place. Being their sounding board builds trust in the recruiting process, and proves you are truly their advocate.

Winning the talent war doesn’t have to be a monumental task. With the right mindset and preparation, your organization can win the battle and set yourselves up for long term recruiting success.

Hiring an Expert

On our blog, we’ve talked about several aspects of what to look for when looking for delivery partners, and today we’re going to take some time to dig into what it means to “Hire an Expert”, and how to identify one. This is a critical skill that really needs to be sharpened if you’re going to be working with someone to facilitate and accelerate your projects. We’re going to look at why you should or shouldn’t hire an expert, and what makes an expert, well... an expert!

We Need Help (Resources)

You’ve decided that you need help with your project and that’s a huge step. The next phase is when it gets challenging. You have to find out WHO can help you. Do you need more resources to do more work or do you have bigger decisions to make? If you just need resources, you’re probably not looking for an expert. Don’t get me wrong, you may need very Sr-level resources with huge skill sets, but you’re looking for delivery and that means you’ll want to screen contractors or use a trusted partner to supply you with proven resources to get the job done.

We Need More Than Just More Resources (An Expert)

When more input is needed to your process than just solid delivery resources, you’re probably going to need an expert… at something. The What and When and Why of that decision is a topic for another post, right now we’re going to dive into what you’re looking for in an expert.

An Expert Is...

An expert is a thought leader, which means that they are well-equipped to engage in your process at levels broader than the nuts and bolts of delivery and can contribute meaningfully across a broad range of team activities. They also have three key characteristics that can make or break an effort:

1. Experts can communicate with the team

   We specifically chose the word “communicate” instead of “talk” or “engage” because communication implies that the concepts that they are conveying are understood more or less intact by the team at all levels, so that aligning everyone happens naturally through the course of regular communication.

   Some teams are resistant to outside input, we’ve seen some pretty hairy conversations develop around hot project topics, but part of communication is wading into the mess and working to sort it out.

2. Experts have opinions and rational, defensible reasons for them.

   An expert will present a cohesive vision for how delivery looks in their ideal world, be able to tell you why this is a good option for your business, and be able to answer the “Why” behind their vision.

   We’ve been in many situations in software development where someone has presented a path forward to me and given me options for two to three different implementation stacks, along with a nice list of pros and cons for each. That’s great, it really is, but doing research and pro/con lists for a tech stack is something we would expect one of our delivery people to be able to do.

3. Experts will know (and tell you) when you don’t need them

   Sometimes the expertise doesn’t match the need or is at the wrong point in the process, or… whatever else. For some reason things just aren’t matched up right. An expert will come to you with these concerns and let you know when the fit isn’t right. In many cases they may even be able to recommend someone in their network who could be a better fit.

   This can be a hard pill to swallow on both sides, but it’s a matter of knowing where personal limits are and understanding that not everything can work out every time. When a mismatched relationship is forced, the stress eventually fractures the relationship, and oftentimes leaves the project in an uncertain state of success or failure. An expert will do everything they can to prevent that.

There are many, many more characteristics that make experts valuable, but the core value around it all is that they will all be dedicated to your success because they know that’s how they achieve success as well.

To Hire, or Not To Hire… That is the Question

Whether or not you need an expert is a highly situational and business-driven decision that will need careful consideration whenever it comes up. It’s important to make sure that when you do engage, that you maximize the value of your expert by taking advantage of their skills and outsider perspective and be open to the ideas they bring to the table. They are opinionated, but flexible, and can shed invaluable light on parts of your process or plan or implementation that we in the trenches are often too close to see clearly.