What’s New in Wearable Health Technology

Think monitoring your health through something you wear sounds a little sci-fi? Think again. Today, more than half of Americans (56% to be exact) own some kind of smart device tracking everything from pulse to sleep cycles and more. While current technology may not yet be able to, say, neurologically control a robotic arm (think Luke Skywalker or Marvel’s Bucky Barnes), wearable tech is rapidly advancing—especially in the healthcare space.

So what’s trending with wearable health technology? For starters, wearables are no longer just for fitness nerds logging steps and recording heart rates after a Crossfit WOD. In fact, health tech has gone from simple hobby to medical-grade and FDA-approved in just a matter of a few years. The truth is there’s something for everybody when it comes to wearable health technology. Here’s a peek at just some of today’s tech changing how we do both fitness and healthcare.

For the everyday Joe (and Jane)

Debuting in 2008, Fitbit quickly rose in popularity and remains a household name in fitness trackers. While early Fitbits captured data on movement, sleep, and calories burned, the technology has quickly evolved to go beyond the basics. Now, Fitbits can measure breathing, pulse and altitude climbed, as well as logging glucose levels (more on that below), and giving feedback on how your body handles stress.

Next up, smartwatches have taken fitness tracking to a whole new level. Sure, the first smartwatches were basically glorified pedometers, but as technology has boomed with new capabilities and ever shrinking components, these compact pieces of tech go way beyond counting steps.

Now anyone can get in-depth health metrics without visiting the doctor’s office. In 2020, Apple released its latest Series 6 smartwatch that monitors blood oxygen saturation, sleep cycles, heart rhythms using FDA-approved electrocardiogram (ECG) sensors, and even more in-depth health monitoring.

For heart health patients

While Apple’s Series 6 smartwatch has heart monitoring functions, the Move ECG by Withings is an award-winning choice for heart health. Not only does this sleek analog-looking device collect your heart rhythm data, but the software analyzes the data and can communicate directly with your doctor.

The Move ECG can also detect atrial fibrillation, a possibly life-threatening condition which can lead to stroke (frightening stat: almost 3 million Americans unknowingly suffer from afib). If you feel an irregular heartbeat or palpitation, you simply press and hold the side button for 30 seconds. Sensors on the back create a medical-grade ECG and can send the info to your doctor or store the data for later.

Monitoring blood pressure outside the doctor’s office is a gamechanger for many heart-conscious patients. Omron’s HeartGuide wears like a wristwatch and allows users to track and monitor blood pressure and pulse fluctuations throughout the day. Inside the wristband, a tiny inflatable cuff fills with air to get the readings. The HeartGuide is also a fitness tracker so users can better understand how their everyday lifestyle affects their heart health.

For the hospital or nursing home patient

When you or a loved one are admitted to a hospital or nursing home, keeping tabs on vitals is a necessary part of healthcare management. But traditional vital monitoring is bulky and leaves patients physically tethered to machines by wires. No, thank you.

Enter the Philips biosensor, an adhesive patch that sticks anywhere on the skin and sends data wirelessly to the healthcare team. Now nurses and doctors can monitor heart rate and respirations—and even be alerted if the patient has fallen or is having a heart attack—all while giving patients more freedom to move around and peace.

Still in development, a Japanese professor has created a wearable biosensor called e-skin. Similar to the Philips biosensor, e-skin monitors heart rate, rhythms, and respirations. But what makes e-skin unique is its super thin application that resembles, well, skin. The “skin” is embedded with thin electrodes that wirelessly connect to a smartphone, computer, or the cloud so doctors can easily monitor patients no matter if they’re in a hospital bed or at home.

For the athlete

Fitness trackers and smartwatches can detect and analyze heart health, sleep, activity, and more. But what about the serious athlete needing to replenish fluids after a killer workout or competition? With any physical activity, dehydration is a real risk. And on the flip side, drinking too much water (called hyponatremia) can be a life-threatening situation and is more common than you might think with endurance athletes.

That’s what led a group of researchers to team up with Epicore Biosystems to release the Gx Sweat Patch in March 2021. Sweat might seem like an unusual fluid to measure, but since perspiration contains sugar, salts, and even hormones, measuring sweat can give a real-time snapshot of overall health.

To use the sensor, simply stick the small patch to the skin and let the sweat come as it may. Two microchannels capture perspiration where it interacts with chemicals that change the color of the patch. Users snap a photo of the sensor with their smartphone, then interface with the app to get recommendations for how much water and sodium to stay balanced and hydrated.

For the cancer fighter

In 2021, it’s estimated 1.9 million Americans will be diagnosed with cancer. Cancer treatment is complex, but often includes regular measurements of circulating tumor cells (CTCs), an important benchmark determining treatment plans. CTCs are usually collected at a routine laboratory visit, but unfortunately the results are often undiagnostic since the blood samples don’t always contain enough CTCs.

That drove University of Michigan researchers to develop a prototype called the Cancer Cell Detector, a wrist-worn device that detects CTCs. Instead of taking a quick blood sample, this new device collects blood over the course of a few hours to ensure enough CTCs are captured to get a diagnostic reading. Still in development, the Cancer Cell Detector is undergoing clinical studies, but proves to be a welcomed piece of wearable health tech for cancer patients in the future.

For the diabetic

Did you know diabetes is the 7th leading cause of death in the US? And 1 in 3 Americans has prediabetes—a condition where blood sugar levels are elevated but not high enough to be considered diabetes—but 84% of them don’t even know it. Yikes. Unchecked blood sugar can cause all sorts of health problems like blindness, nerve damage, heart issues, skin conditions, hearing impairment, and even death.

At DeveloperTown, we’re excited about changing the landscape of diabetic care and saving lives with wearable tech. One of our favorite products we’ve had a hand in developing is a diabetic tool for Fitbit integration. Some Fitbit users can now track their blood sugar levels over time, set personalized ranges, and since it's joined with a fitness tracker, see how lifestyle and exercise affect their blood glucose levels.

For the [fill in the blank]

The future of wearables is only limited by our imaginations. Have an idea for a health product or tech integration? We’re here to help. At DeveloperTown, we know the ins and outs of wearables, including healthcare technology. Contact us today and lets flex those creative problem solving muscles together.

There’s no way around it; turnover is a bear. We’ve likely all been a part of a team that experiences ill-timed or, at best, unexpected turnover. Even in writing this, I squirm at the thought of the scrambling to backfill, the difficult conversations with stakeholders, and the pressure that mounts while desperately working to get a new resource up to speed with an eye on dwindling velocity. Does any of this sound familiar?

Why is that for so many organizations, developer turnover comes as a surprise? Just a quick look at the numbers shows the simple nature of the industry landscape of which we are all at least implicitly aware. According to the US Bureau of Labor Statistics, demand for software developers is on the rise, projected to grow by 22% by 2029—a staggering trajectory when compared to the average projected growth rate across all occupations, paling in comparison at a meager 4%. In terms of new jobs in the application development space, 310,000 are expected to be created in the same time period. Simply put, demand for developers is up and the sheer volume of employment options is far from gratuitous.

Given the industry employment landscape, the question of whether or not turnover will happen is not a question worth asking. It will. And while a healthy focus of building employee retention is crucial, an equally crucial endeavor is positioning your product teams to handle turnover when it does happen.

As with all businesses, emphasis on the balance sheet is crucial to bottomline health. An issue with this emphasis, however, often arises in the tension between business value add versus real value add. Put into context, the unchecked objective of eliminating as much time as possible spent on business value add objectives curtails any meaningful effort to focus development team capacity on adequate succession planning. This common scenario, played out to its logical end, can leave teams feeling debilitating pressure when someone on their team moves on to a new opportunity, and plagued by the questions of how much time will be spent helping a new team member get up to speed.

“How quickly will a replacement be brought in?”

“What additional slack will need to be picked up in the meantime to ensure objectives are still met?”

“How long will it take to get back to our previous velocity?”

Such questions not only distract the team and detract from their work, they can also be the precursors to subsequent burnout resulting in additional turnover.

So what is one practical step that can be taken to help mitigate the negative effects of product team turnover?

The concept of minimal viability, generally applied to Agile product development, just may be the cure for what ails you.

Just as product teams seek to define and develop the minimum requirements necessary to deliver a testable piece of software and continue iterating from there, so too can succession planning be approached from the perspective of minimum viability. Think about it, or better yet, provide a bit of time for your product teams to think about it.

What are the bare minimum requirements of a viable succession plan within the context of the team’s work?

Focus in on the must-have features and lean on your Scrum Masters to compile the plan for their teams. From there, iterate. Take each instance of turnover (and hopefully there aren’t many!) as an opportunity to reflect on and improve the onboarding process, a perfect conversation for a sprint retrospective. And understand that the upfront costs associated with planning will yield dividends down the road.

In doing so, not only will the members of the team feel better cared for—especially new members backfilling open positions—but should turnover occur, velocity will be better maintained in spite of it.

And chances are you’ll see the value of that upfront investment in your teams jump across the balance sheet.

You’re sitting nervously in the cold, antiseptic-smelling room waiting for the doctor to show up. They finally rush in, only to spend the majority of their time staring at a screen. Their fingers fly, inputting as much data as they can, spending only a few minutes making eye contact and actually examining you. Then they rush off in a flurry of scrubs and screens.

All too many of us can relate to this experience.

It’s easy to blame the doctor for being so harried and impersonal. What a terrible bedside manner, we might mutter. But what if there’s more to it?

42% of physicians struggle with burnout. Pandemic-related stressors, overworking, and lack of respect and autonomy are just a few factors doctors cite as causes of weariness and overwhelm. But surprisingly, some of the very tools created to ease healthcare burdens are also seriously contributing to the problem.

As you know, around here we are tech fanatics. Building agile and creative tools to help businesses solve problems and capture opportunities gets us all kinds of giddy. But we know that sometimes tech gets in the way and actually makes things worse.

When new tools are developed without the proper input, foresight, and strategy, it’s a recipe for disaster. And we’re watching this play out in the healthcare space in a big way right now.

Physicians report “too many bureaucratic tasks” and “increased computerization of practice” as some of the leading causes for burnout. And today’s surge in telemedicine and our constant digital connection has blurred the line between work and home more than ever.

Truth be told, most doctors just want to treat patients. They want to help and heal. And they want to have a life outside of work. But ever-changing data capture requirements, shifts in telemedicine, and other tech changes seem to take them further and further away from the heart of why they become physicians in the first place.

The result? Doctors are exhausted, frustrated, discouraged, and even experiencing symptoms of despair, depression, and PTSD. The pandemic has shown us more than ever how much we desperately need our frontline health heroes. So it’s time we started paying attention to what they need from us.

Healthcare tech tools are often created with one population primarily in mind: the patient. While patient experience obviously matters, the cost of minimizing or ignoring altogether a tool’s impact on the physician is great. Tech that isn’t doctor-friendly often creates more work, more frustration, and more burden than anything else.

Business author and speaker Tom Peters shares this, “Put your customers first and your people before anyone else. If your employees are happy and you treat them right, it will naturally result in them treating your customers right. This is why your customers can never be happier than your employees.”

In the same way, happy doctors equals happy patients. We can’t expect patient care to improve after handing over tech that makes life miserable for physicians. They don’t need one more thing in their already hectic lives. Clunky, disruptive tech just adds to the heavy loads they already carry.

Our client and friends at Uppstroms get this issue more than most. Founded by a physician, this startup is creating a machine-learning app that proactively identifies patient need. And they’re going about it the right way—looking at how the tech will reduce physician workload and not add to it; examining ways to integrate the tool into natural workflows to minimize disruption.

When it comes to developing new healthcare tech, we have to start listening to physicians and involving them heavily in the process. We owe it to them now more than ever.

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.