Tech industry / 3

When it comes to offshore software development teams, managing quality and risk creates value. But you also need experienced leadership and oversight for long-term success. Simply adding offshore bodies to a project rarely works, and has diminishing returns.

Here are some process tips for mitigating risk and getting the most value from an offshore team.

• Also leverage an onshore development partner for leadership and critical systems design. They can create and direct strategy, ensure developers follow patterns, address compliance and security concerns, and perform code reviews to ensure quality. They can also write better code faster, which best suits critical systems development. This is what we do at Fynydd and it works.
• If possible, your offshore team should mirror your operating hours. Otherwise communications, troubleshooting, and overall progress will lag. It can be beneficial to have expanded availability for handling off-hour requests, but that means the offshore team needs decision-making authority. Otherwise someone in the organization will also need to be available during those hours.
• Try to get dedicated resources for the long term. When there are offshore staff changes, require that they fully train the replacement(s) before additional staff are brought in. It takes time! New developers, even when they are superstars, need to learn a platform's ins-and-outs before they can meaningfully contribute.
• Be explicit about who is running the project, give them the appropriate decision-making authority, and enforce a workflow that puts them between ideas and action. Ideally this would be a lead developer from your onshore partner.
• If the offshore team has novice developers or otherwise low-performers, make sure they are in a learning role and not expected to work on key infrastructure.
• Perform code reviews. Bad or inefficient code should not be tolerated and is a learning experience that can make your offshore team better.
• Rely on your lead development partner to facilitate communication. If you find it difficult to communicate with your offshore team, your lead development partner has experience in picking up the nuance, including technical jargon that's hard to understand in any language.

Avoiding the big problems

Some of the issues you'll encounter can be avoided by engaging with an onshore development partner. Here are some tips for keeping the app or service quality high and the risk low.

• A proper architecture and coding patterns are critical to long-term success. Without a good evolving architecture and consistent coding patterns maintenance is difficult, code readability suffers, and security vulnerabilities are harder to avoid.
• Compliance is a bear, even with experienced developers. This can range from ensuring organization brand standards, to complying with regional legal requirements (like GDPR), and avoiding copyright violations. There needs to be a focus on these concerns which yields appropriate strategies and resolutions on a consistent basis.
• Bad code quality is a risk. It's not just about performance and user experience. Bad code could leak information or have vulnerabilities. It could allow bad actors to misuse your app or service. Worse yet, it could facilitate the abuse of your customers.
• A focus on security is not optional. Properly securing an app or service requires a development team that not only has a security focus, but also the experience and awareness required to implement and maintain a solid security posture. The team members have to be vetted resources with no geopolitical encumbrances and a level of trust commensurate with the app or service in question. For example, bank or government clients may require background checks.
• Maintaining intellectual capital is crucial. You invested time and money into building a knowledge base as well as an app or service. You need to ensure that the knowledge gained building your app or service will not vanish into the ether.

Want to know more?

There's usually more to the story so if you have questions or comments about this post let us know!

Do you need a new software development partner for an upcoming project? We would love to work with you! From websites and mobile apps to cloud services and custom software, we can help!

Planning out a long-term strategy for your web project can really pay off. We were recently reminded of that when we were asked to create a mobile app (iOS and Android) for a web-based platform we designed and built several years ago. The platform is Coursabi, a learning platform that ensures growth at each milestone for everyone on your team. You can check it out at https://coursabi.com.

When we created the technical strategy we knew that a mobile app was a likely roadmap item. So we chose ASP.NET Blazor as the core platform technology. It allowed us to build a web app that felt like a single page app (SPA). And it gave us several hosting models: server, WASM (WebAssembly), and hybrid mobile. The most intriguing aspect of the Blazor Hybrid model is that unlike hybrid apps of the past, there is no web server running on the mobile device. Instead, all the C# code is compiled to native .NET code, and the web view (an embedded web browser) is only used to render the user interface. So the app runs as a native mobile app!

We knew that some features of the platform would have to be altered, since the mobile app has no web server. For example, Coursabi supports the SCORM format for external learning content. And due to security restrictions, they needed a host with a trusted root certificate. So moving that out of the platform and handling the routing changes were both necessary, but totally doable.

Another benefit of a mobile app version of the platform is that in many ways it also simplifies the security model, since the app is only running on the local device, whereas a hosted app needs to manage user state, among other concerns.

If you have an ASP.NET-based web application, you can still leverage Blazor Hybrid to turn it into a mobile app. It just needs to first be migrated into a Blazor app. I'd also recommend reviewing your web app for opportunities to make it as mobile-friendly as possible. You don't want your mobile app to look or feel like a website. But those changes not only get you a great mobile app, they also improve how your app looks and feels in a mobile web browser. So you get twice the value.

Want to know more?

There's usually more to the story so if you have questions or comments about this post let us know!

Do you need a new software development partner for an upcoming project? We would love to work with you! From websites and mobile apps to cloud services and custom software, we can help!

If you're not already familiar with the term, vibe coding is a new way of coding that allows people to use AI to create software without needing to know how to program. In the best case it empowers people to be creative and build tools that help with work or play, as low- or no-code solutions have always done. In the worst case it gives the impression (or rather sets the expectation) that they can literally build anything, and that software developers are a thing of the past. As with most things in life the truth of the matter lies somewhere between these extremes.

Vibe coding can be a great way to learn programming (and just have fun). It could save you hours of research, though AI is notorious for confidently giving you the wrong answer.

In many ways vibe coding is a variation of a theme. For many years there have been services to help non-programmers create tools. Some of the more recent iterations are low- and no-code solutions using drag and drop and interactive prompts. An example of this is Zapier, which allows you to connect various services and platforms to create workflows, among other things. One way you could use it would be to create a workflow that syndicates a blog post to your social network accounts or emails subscribers. In these cases the technology, hosting platform, security, and protocols are abstracted away so users can focus on the what and not be concerned with the how.

Vibe coding differs in that it requires that you also have an understanding of the how. In the example of syndicating a blog post, you would need to have some understanding of how each connected service handles communication with third party services, how to configure access for each platform, how the app needs to be hosted, how to deploy the app, and how to ensure the app is secure. You also need to know how to set up, use, and maintain a development tool chain, though some services may generate/host projects or compile code for you.

AI is trained on code written by people in the past. The word "train" implies that it's learning how to code when in fact it's just indexing the data in a way that allows the AI to regurgitate answers derived from that information. As technology changes AI needs to ingest new code written by software developers in order to keep up.

So if your choice of using vibe coding is simply a way to learn programming (and just have fun) you should go for it!

Otherwise, below is a checklist of good reasons to use vibe coding to build something. Keep in mind that complexity and tolerance for adventure are always subjective.

1. You're tech savvy and interested in coding
2. Your timeline is long or there is no deadline
3. The app is reasonably simple, like a to do list or simple expense tracker, or is a prototype
4. The app does not need to be hosted in the cloud
5. You don't need to use complex third party service integrations
6. The app cannot be created using an existing software package, like Claris Filemaker, etc.
7. Security is not a concern
8. Reliability is not a concern
9. Scalability is not a concern
10. Localization is not a concern
11. Look and feel of the app is not a concern
12. Data backup, recovery, and code versioning are not concerns
13. Using the latest development patterns, languages, frameworks, and APIs is not necessary

If any of the previous points are an issue, here are some good reasons for using a low-/no-code hosted solution instead.

1. You're not very tech savvy and/or not very interested in coding
2. The app is no more than moderately complex, like a service to syndicate blog posts, or is a prototype; again, complexity can be subjective
3. The app can or needs to be hosted in the cloud
4. The app needs one or more third party service integrations
5. Feature alignment; the service offers exactly what you need
6. The look and feel of your app can be achieved with the hosted service
7. Pricing for the hosted service meets your budget
8. The hosted service provides disaster recovery options

Professional services

This is merely scratching the surface. As a professional software developer I can tell you that the devil is in the details. One example is how important security is nowadays, and how challenging it can be to maintain a proper security posture even when you know how to code. Besides, with the right software development partner you'll end up with a better result, and stay within your timeline and budget.

A professional software development partner can handle all of the gaps and requirements you may have identified in the previous lists, including:

• Tight timeline
• High complexity
• Security concerns
• Reliability concerns
• Scalability concerns
• Deployment, hosting, and/or third party integrations
• Changes to support hosting or third party integration changes
• Technology options
• Product evolution and upgrades
• Strategies for disaster recovery and data backup
• Strategies for scaling the product
• App look and feel
• ...and so much more!

Want to know more?

There's usually more to the story so if you have questions or comments about this post let us know!

Do you need a new software development partner for an upcoming project? We would love to work with you! From websites and mobile apps to cloud services and custom software, we can help!

.NET 9 was officially released during .NET Conf. This release feels like a LTS release; full of speed improvements and quality of life features and refinements, even if you only use it as a drop-in replacement for .NET 8.

It's about time… NIST has updated their password formatting recommendations to better align with modern use and the reality of how we use passwords. For example, the new rules bar the requirement that end users periodically change their passwords. This requirement came into being decades ago when password security was poorly understood, and it was common for people to choose common names, dictionary words, and other secrets that were easily guessed.

Qualys has a free tool named SSL Labs that anyone can use to check the security of their website TLS certificates and certificate hosting configuration. This is an frequently overlooked area of securing a website and we highly recommend using it on your own website. In fact, we use it on all our website projects to secure our client websites, and dog food it for fynydd.com (we score an A+ by the way).

Features

The SSL Labs tool will evaluate a ton of certificate hosting exploits like BEAST, POODLE (SSLv3), POODLE (TLS), Zombie POODLE, GOLDENDOODLE, Sleeping POODLE, and more.

It will also scan your server's TLS/SSL protocol support to ensure that you're using the latest version (TLS 1.2 at the time of this writing) and that your server has disabled legacy protocols to prevent protocol fallback attacks. In fact, if you're hosting with Microsoft Internet Information Service (IIS) we highly recommend installing the "Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2" PowerShell script to lock down your server TLS/SSL protocol support.

Want to know more?

There's usually more to the story so if you have questions or comments about this post let us know!

Do you need a new software development partner for an upcoming project? We would love to work with you! From websites and mobile apps to cloud services and custom software, we can help!

Being a pragmatist when it comes to software development, I generally prefer simple solutions whenever possible. So when clients are faced with the challenge of determining which features to add to their products, as a starting point I usually recommend looking at user value versus cost to implement.

Given a progressive value scale from a “cup of coffee” at the low end and a “house” at the high end, we can easily see where the best choices lie.

Looking at the first row in this example, if a user values a feature at “house” and your cost to implement is a “cup of coffee” this feature addition becomes a no-brainer.

Likewise if a user values a feature at a “cup of coffee” but it will cost a “house” to build, it's certainly a feature to avoid implementing.

There may be some diamonds in the center blue area, but more information is usually required before we make those decisions.

Want to know more?

There's usually more to the story so if you have questions or comments about this post let us know!

Do you need a new software development partner for an upcoming project? We would love to work with you! From websites and mobile apps to cloud services and custom software, we can help!

Apple's decision to make macOS look and feel more like iOS is aspirational, certainly. If users could seamlessly switch between operating systems and retain muscle memory it would be a big win. It's no wonder that Apple decided to do this with macOS 13 Ventura.

But in practice, Apple's zeal for consolidation has created some real problems for users. In many cases it feels like one step forward and two steps back. I can see how iOS power users may welcome most of the changes to macOS, but that position smacks of Stockholm Syndrome to me.

One of the best examples of this is the redesigned System Settings, which is a mess. I've given it months to “grow on me” and it has… like a fungal infection. The settings are (dis)organized into a single column of top-level categories in a seemingly random order. Devices running macOS have wide screens, so restricting the top-level categories to a single narrow column is an artificial limitation. And it can’t be remedied by resizing the System Settings window because only its height can be changed.

And the organization? macOS has a much deeper and more broad collection of settings than iOS. So as difficult as specific iOS settings can be to find on an iPhone, it’s near impossible on a Mac. And making it worse is the fact that some settings have been organized out of existence, spread out into disparate, counterintuitive categories. Want to tune all your power and sleep settings? You may have to explore a dozen settings categories to find them when they could have been put into an “Energy” category or something similar. Luckily there is a search feature. Without it I’m sure users would be surrounding the Apple Campus with pitchforks and torches.

Also part of this convergence initiative is the Apple decision to make physical keyboards work more like the iOS virtual keyboard, which changes contextually. The difference is that the iOS keyboard changes in appearance so you can infer what's expected. This means that, for example, sometimes you can use the delete key to remove characters to the right of your cursor, and sometimes you can't. It's like an infuriating game. And now when you press and hold an alphanumeric key it no longer repeats, in favor of a popup with extended characters (e.g. foreign characters with accents and ligatures). I suppose that’s handy for people who write in a foreign language. But you would assume that it would be an option, not a change to the original default key behavior. Your keyboard isn’t broken. Apple made it better YOU'RE WELCOME.

When asked, most people think that software development is coding; the physical act of programming apps and platforms for servers, computers, and mobile devices. This is not the case.

Software development is the process of solving problems through software. It's a creative process that is centered on discovery and adaptation which uses tactics like programming (coding) to accomplish its ends. Likewise, software development is not the act of reusing existing software for a new purpose. That's just copying bits.

So it is important for those involved in the software development process to understand and acknowledge the following key aspects.

Discovery and adaptation is the focus.

Understanding the problem domain is the key to a successful software development process. And we know the least about a problem domain at the outset. So it doesn't make sense to plan everything out at the beginning. Software development is an exercise in learning. We learn more and more about the problem to be solved as we move through the process. And as the problem domain comes into focus we should be refining or redefining what we should be building as we learn.

Mistakes will be made.

Mistakes help us solve problems and are one way in which we learn. Embrace them. Plan for them.

We cannot predict the future.

Perfect plans are usually perfectly wrong. It is impossible to perfectly know the steps, mistakes, discoveries, interruptions, and goals for a project, nor the time impact of each, all in advance.

Estimates are guesses about the future.

Great software doesn't just manifest in one go. It springs forth in a deficient state and evolves over time. This makes guessing about its future state with any accuracy a fools errand. It also means that creating precise specifications for those guesses can be a waste of time.

Accuracy and precision are not the same. Something can be very precise but horribly wrong. This has been shown by various studies, including those in the Microsoft Press book Rapid Development by Steve McConnell. According to the book it doesn't matter how diligent or thorough an estimate may be. The data shows that when compared to a more broad, high-level, or piecemeal approach based on past experience, the error bounds are largely the same.

Right-fit planning works.

We must understand the level of precision that makes sense. For example, it doesn't make sense to plan an entire project with the same precision as planning next week's work. Likewise, planning specific deliverables for dates far out into the future is also problematic. Small time horizons increase the accuracy of our guesses.

Release often.

By deploying changes frequently, we allow the entire team to steer the direction of the project early and often. This agile approach will ensure that the final product performs as it should for its users.

Want to know more?

There's usually more to the story so if you have questions or comments about this post let us know!

Do you need a new software development partner for an upcoming project? We would love to work with you! From websites and mobile apps to cloud services and custom software, we can help!