The decision to buy an off-the-shelf solution or build a custom solution is one that every business must make. It’s a difficult choice, as there are many pros and cons of building custom software. To help you make the best decision for your business, we’ll a look at both software acquisition approaches.
Purchasing Off-The-Shelf Software
When it comes to purchasing software, there are several advantages to consider. First and foremost, buying commercial off-the-shelf (COTS) software is upfront cost savings – both in terms of time and money. When you purchase a pre-built software solution, it’s often much faster (and cheaper) than attempting to build something from scratch.
Additionally, a large user base means that the COTS has likely been tested by thousands of people. This limits the possibility of bugs or glitches before you incorporate the software into your workflow. This means less risk on your part, and fewer headaches down the road due to compatibility issues or other problems with an untested system.
Of course, there are also downsides: namely, lack of customization options and potential vendor lock-in issues. These could be especially problematic if they decide to stop supporting their product, or get acquired by another company. Additionally, since pre-made solutions need to cater for a wide range of customers they may not always provide intuitive user interfaces or enable personalization options. This can leave users confused, or force business to change their processes to match the software.
Lastly, if the “out-of-the box” solution doesn’t quite meet all your needs, it tends to be difficult – or impossible – for it do so without significant customization. Theses customizations can be expensive and unstable, negating the cost savings from buying pre-made solutions.
Building Custom Software
One major advantage associated with building custom software is having total control over the product. Businesses can ensure that the system meets all their needs, without the limitations of “off the shelf” products. This allows for greater internal adoption and implementation as it lets the software conform to the business, rather than the business conforming to the software.
Additionally, custom software allows for greater flexibility and scalability. Since the code for these applications is proprietary, companies may find themselves with a competitive advantage against those using shelf systems. Custom software allows companies to respond to user feedback quickly by developing better tailored versions to improve user experience.
Lastly, as businesses grow the shortcomings of a one-size-fits-all approach are magnified. Inefficient processes amount to hundreds of lost hours throughout the year. All while recurring expenses rise due to increased users or added features. Since businesses are stuck “renting” technology, they are unable to reap the benefits of owning their technology. In many cases, medium-size businesses are able to see positive ROI in as little as three years by developing their own custom software solutions.
Conclusion
The needs of every business are different. Understanding the pros and cons of each software solution alongside the specific profile of your business is critical to making the right decision. At Sigao, we invite you to do the research with us. We’re happy to help you assess the software needs for your company.
As veterans of the custom software industry, our team has encountered countless questions about the creation of custom software solutions. However, few questions are as difficult to answer as the very first one.
“Do I need custom software?”
Software is wildly complex, both from an engineering perspective, as well as a business value perspective. Today’s applications can touch so many aspects of an organization that accurately gauging the investment can be a challenge. On top of that, no two engineering firms are the same. Some may provide ultra-specialized engineering services for one aspect of the project, while others may provide broader, more consultative services that cover more of the project scope.
The natural reaction to attempting to process too many choices is to intuit the answer. To try to “feel” that the variables are pointing one direction or another. This is dangerous as it leads to Confirmation Bias, giving you the impression that all the information you discover appears to point in the direction you want it to point.
In this article, we’ll discuss some tangible aspects to consider that will provide a framework for making the decision. Keep in mind, this is too complex of a subject to cover in one article. Our hope is that this information provides valuable measures that help you feel more confident about the process.
Analyze the “Why” Behind Your Custom Software
Every software project begins with the same thing: a problem.
Unfortunately, people are good at solving problems.
Take a minute to think through the last problem you solved. It can be anything. Maybe your phone wasn’t working, or your car was making a weird noise. Whatever it was, think about how you instinctually responded when you discovered the issue. I’m willing to bet that the first thing you did was immediately start trying to figure out the underlying cause.
Did you mull it over in your head, vetoing unlikely scenarios and coming up with new explanations. Maybe you googled the issues, trying to find others who have solved this problem. Whatever path you took, its very likely that you got sucked into finding a solution without paying much attention to the problem its self.
People are hardwired to solve problems. We’re good at it, and by and large, we enjoy it. Unfortunately, that aptitude leads us to dive into solutions, while giving the problem only a cursory glance. Maybe the cost to fix the problem isn’t worth it? Maybe the problem opens up doors to fix other areas? What if there’s an ugly, but effective solution that’s far easier than the obvious solutions?
For small, every day problems, the downside of ignoring this kind of deep analysis is minor. A few hours here, a few dollars there, no big deal. Yet, software projects are huge investments, with vast consequences. Most problems are solvable, but the real question is should you solve them?
Know your problem, ignore the solution
Nothing related to a solution matters at this point. Not the price of the solution, not the technology (or lack there of) of the solution, only the problem. Our team consistently encounters people who “know” what software frameworks we need to use to solve the problem. Yet these people often are not able to describe the problem in detail. They’ve allowed themselves to dive into the solution without truly knowing the value of the problem, which makes the decision little more than a gamble. Before moving forward, these are some of questions you should be exploring:
How many people does this problem effect?
How much time/money do you lose from these effects?
Are there 2nd or 3rd parties affected by the primary party’s issues? How much time/money do you lose there as well?
Are there multiple facets to this problem? If so, which is the most valuable to solve?
Are there adjacent issues that you can address in tandem with the primary issues?
The more you can understand the problem, the more you can assist other’s to build a good solution.
Why knowing your problem is so critical
The less you know about the value of the problem, the more you end up guessing about the value of the solution.
At its core, a software project is a continuous cost/benefit problem. You expend X amount of effort for Y amount of return. If done correctly, Y ends up significantly larger than X. Because of this, one of the largest factors in a successful project is how well those involved understand the problem.
The less you know about the value of the problem, the more you end up guessing about the value of the solution. Each decision becomes a gamble, rather than a calculated risk. And you will be making decisions if you continue down this path. As the owner of a project you will face a constant stream of decisions related to the value of your solutions.
Do you sign off on using a 3rd party tool that costs $100/month, but will end up saving 2 months of project work? What if that feature is only solving a problem that costs a handful employees 10 minutes per day? Engineering groups can provide information, and some (Sigao being one of them) can even assist in analyzing those choices. But, the final decision must come from those who understand the problem the best.
The next reason is perhaps the most important. It’s what elevates project outcomes to to their maximum potential:
Extreme understanding of the value of the problem allows for the most creative solutions.
Knowing your problem fosters innovation
Knowing what is and isn’t important allows the engineering team to propose creative solutions. My favorite example of this is what happens in some of our initial discovery meetings. People will often approach us to build a project having already landed on a desired solution. They’ve spent weeks or months imagining a complex solution that addresses ALL their problems, without knowing the value of those problems individually.
This is a common scenario, which we address with an array of discovery questions. We try our best to help our customers refined down the most valuable aspects of their solution. During that process we occasionally encounter situations where the value is so concentrated on one aspect of the problem, it allows us to bypass the majority of their requirements. If only a handful of requirements are worth the investment, why bother with the others?
The results are often eye opening. Given a narrowed scope, the team is free to adopt a more Rapid Testing mindset. We’re able to suggest ideas that may not even involve writing code, but will solve the problem quickly. This allows the customer to assess portions of the solution individually before committing to a large scale system. Sure, these solutions are typically “quick and dirty”, but the amount of value they provide negates the downsides.
Its not uncommon for our customers begin a meeting envisioning a $50k+ system , only to leave the meeting with a way to solve most of their problems for free. All because they were able to recognize the most valuable problems to solve.
That’s the power of understanding your problem. When you know what’s most valuable, you gain the ability to make more intelligent decisions about where you invest your time and money.
Long Term “Why” Behind Your Custom System
One of the biggest issues we struggle with in the software industry is conveying the benefits of a custom solution. It’s difficult for people to get past the initial shock of the price, and a lot of that is because they haven’t truly considered the problem their solving.
Custom software systems are like sports cars. Expensive to build, expensive to maintain, but capable of doing amazing things. Part of knowing your problem is knowing how much the value of the solution builds up over time. If you a development team quotes you $300k for the solution, is that bad? Maybe. What if it will save you $70k per year and will turn a profit in 3 years? What if you’re currently paying $40k/year in subscription costs which will disappear after the project?
Think back to the “adjacent issues” you explored. Could owning your own data provide more opportunities for value over time? Could you later pivot your solution into a product that you then sell to other companies similar to your own?
Time is a powerful factor when considering the problems you’re solving. Solutions typically provide value for long after the initial project cost.
How Much to Invest in Custom Software
By now, lets assume you have your problem mapped out. You know how many people it affects, how much they lose, and how much money you’re losing by not addressing the issue. The next question is, can you feasibly afford the solution?
Custom software is expensive, and there’s not much you can do about it. Even if you are absolutely convinced of the value of your project, there will still be significant investment to get to the end goal. There’s no cutting corners if you expect good project outcomes, which is why its so important to know what you stand to gain. We plan to cover this topic in more detail in later articles, but for now we’ve provided a reference table for you to plan against.
Keep in mind, many factors affect these prices. Some seemingly difficult features are solvable in days, while others that appear simple can take weeks or month to accomplish.
Reference Table For Estimating Project Costs
Project Type
Price Range
Description
Simple Marketing Website (Contractor)
$1-5k
A simple marketing website meant to display information, built by an independent contractor. Primarily needs to look good, function on mobile. Functionality would be limited to simple contact forms.
Simple Marketing Website (marketing firm)
$5-30k
A simple marketing website meant to display information, built by an experienced marketing firm. Primarily needs to look good, function on mobile. Functionality would be limited to simple contact forms. Typically would include more robust designs/mockups, more help with hosting, as well as maintenance and trouble shooting.
Proof of Concept Web/Mobile App
$30-70k
Web or mobile app, built by an engineering firm, designed to show that the intended functionality is possible. May not be complete, or visually appealing. May not scalable. These are typically used to attract investors.
Mid size Web App
$70-300k
Web or mobile app, built by an engineering firm, designed to accomplish a business function. These may absorb several business areas, allowing the company to remove multiple paid products from their workflow. This price range may also be applicable beta product launches, depending on the complexity of the product.
Enterprise Web App
$300-1,000k
These are large, overarching systems that touch multiple aspects of a business and hundreds of users. These systems have multiple integrations with other systems, multiple roles throughout the organization, and strict uptime requirements. For new products, this range would likely cover several major versions of an early stage product. If promoted properly, a new product with this much investment should typically be generating revenue and attracting large investment firms.
Follow Through with your Custom Software Project
You know your problem, and you have an idea of what its going to cost. Now what?
If you have the corporate backing or funding to move forward, the next step is to start evaluating vendors. Spend time finding a group that’s trustworthy and has a proven track record. Make sure their clients willing to vouch for their capabilities. Find out if they hide the development team, or let you interactwith the people building your solution. Finally, make sure their contracts are set up to share risk on both sides of the project, rather than pinning it all on you.
Most of all, find someone you get along with. There WILL be stress, there WILL be miscommunication. The best way to navigate that is by working with someone you trust.
Final Thoughts
Assessing whether you need custom software is a difficult task, but it doesn’t have to be guesswork. Sure, you won’t always find perfect ways to assign value to the problems you’re trying to solve. You won’t always have all the information you need to make a perfect decision. However, with a little effort, even the most complex problems can be evaluated and broken down in a way that empowers you to make better decisions.
As providers of software development services, we encounter clients from a wide variety of backgrounds and industries. All companies, from startups to mega corporations, have business problems that can be solved with technology solutions. However, software development is a wildly complex skillset that is often made less comprehensible by ever-evolving jargon and practitioners who are only familiar with talking amongst other practitioners. This leads to a massive knowledge imbalance between buyers and sellers, which in turn opens the door for unskilled teams to take advantage of unsuspecting buyers.
Over the years we’ve heard countless stories of buyers having bad experiences with their software projects (in fact, we’ve helped fix a couple of those projects!). Whether its buying software that isn’t needed, entering into unfavorable contracts, or simply not being aware of the expenses involved with a project until its too late, the buying process is filled with potential pitfalls that can affect the overall success of the project.
Because of this, we’ve decided to provide an educational guide for buyers. This should not be considered a comprehensive checklist, but instead a starting point for further research. Our goal is to help prepare you for what to expect, what to ask, and what you should know to avoid making costly mistakes.
What should you think about before starting the process?
Many potential buyers have not fully considered what building and owning a software system means. This is a big undertaking with big ramifications for your business. Take a few minutes to consider the following pitfalls and misconceptions that new buyers deal with.
Software is expensive
This is the number one thing that most people are surprised by when they first start looking into a software project. The skills required to properly build a software application take many years of constant training and dedication to refine. What further complicates this issue is the relatively low barrier to entry. Virtually anyone can take a few free courses and call themselves a developer, and many people do. As the market saturates with new, inexperienced developers, it leads buyers to assume that it’s an easy/common skill set that shouldn’t cost much.
Worse yet, lower skill developers typically focus on skills that produce visually appealing, user facing code, while not training on how to scale large applications. This means that buyers often don’t realize their software is broken until they attempt to onboard users and their money is already gone.
It can not be overstated how often we encounter buyers with broken code bases and empty budgets looking for a quick fix to system that is beyond saving.
While the lure of cheap developers is a powerful one, keep in mind that the vast majority of projects made by low skilled developers need to be scrapped. While prices can vary wildly based on geographic location, a typical US based proof of concept project will run anywhere from $50,000-100,000. Hourly rates for talented on shore development firms will likely be anywhere from $110-185/hr, and potentially higher for teams that provide DevOps engineers and have enterprise software experience. Talented developers are worth their weight in gold, and their salaries reflect that.
Think of software like building a skyscraper. Low-cost developers have learned how to poor cement, place rebar, and decorate a pretty facade, but don’t have extensive training in large scale mechanical stresses, foundation design, and resource management. The building will look fine for a while, but as it grows the cracks will show and eventually it will fail and need to be rebuilt.
Not all languages and frameworks are equal
Every development team has their favorite programming language and frameworks, and they will likely give you reasons why you should allow them to build with that language or framework. While it’s true that most code behaves in roughly the same way, your job from a business perspective will be to support this application long term. That means your project needs to be written in a language that is popular, and likely to be around for a while. The developers may love a new fad language that’s just “so much better” than the older languages, but if the new language dies out in six months you now have to A) stick with that team forever, or B) find some other shop using this niche, probably expensive language.
We encourage you to research application languages and frameworks on your own, but this 2021 Stack Overflow survey is very helpful.
Your business needs should be defined
Think long and hard about what problem you’re solving and how much money you’re losing by not solving it. You don’t have to know HOW software will fix the problem, that’s for the development team to figure out, but you do need to know WHAT problem you’re fixing and how much money that fix will save you over time.
If the team doesn’t actively understand and work towards solving your business problem, get a new team.
On the flip side of this, understand that business problems have a lot of solutions, and the most appropriate solution may not involve the specific technology you have in mind. Our team regularly encounters buyers who insist that they need an app yet describe a business problem that does not fit a mobile app delivery model. The best project outcomes occur when business experts focus on business problems and technology experts focus on the best technology to solve those problems.
Software projects don’t end
This is another misconception that tends to blindside buyers. Most people assume that a project will start on a specific date, run for a specific time, then end. But the reality is that software expenditure ends when the problem no longer needs fixing. At a minimum, the software will incur monthly hosting and maintenance costs. You cannot leave modern software without maintenance because there are so many connections to other applications that any number of external factors can destabilize your system. Your system will need to be actively monitored and fixed as errors occur.
However, errors aren’t the only things to consider. Most projects end up identifying other business issues beyond those originally in scope. Virtually all businesses have an ever-increasing backlog of business problems to solve, each with a corresponding increase in revenue or decrease in expenses.
If the business problems are being solved properly, the economical solution is to continue development indefinitely.
You MUST be hands on
Custom software products are, by definition, creating solutions to non-standard problems. If the problem were standard, there would already be a software product available to solve that problem. That means that the quality of your solution will depend entirely on how clearly and frequently you can communicate your business problem to the development team. Nothing predicts negative project outcomes like buyers who are not willing to be involved with their custom solution.
Think of it this way, if you had an idea for a brand-new car that doesn’t behave like any car in existence today, would you assume that you could describe it to engineers one time and then come back in a few months and have the perfect car? No, you would need to constantly discuss the new functionality you want and sign off on changing the functionality that may not be possible.
Common terminology all software buyers should know
Knowledge of common development terms can greatly increase your understanding of the project, as well as the competency of your potential development partner. There are nearly endless development terms, but we’ve done our best to choose those that most apply to team’s ability to produce quality work.
Agile
Agile is a software development philosophy that focuses on iteration, quickly assessing new information, and changing directions as needed. Methodologies that use Agile principles are proven to result in better project outcomes over a shorter timeframe.
DevOps
This term is used to encompass a wide range of activities surrounding the successful operation of development teams. DevOps is concerned with making sure code is deployed consistently, with minimal bugs, and with many contingencies to prevent system failures. Robust DevOps practices are mandatory for large, enterprise applications.
Environment
In software development, the “environment” typically refers to an instance of the system that is set up for a specific purpose. Environments allow the engineers to change specific variables for various stages of the development process.
Development Environment
This is where engineers modify and expand code. Development environments are typically unstable due to large scale changes, and 3rd party integrations (particularly those that charge money) may be disabled.
Test Environment
This is a more stable version of the system where manual testing can happen. It’s built to simulate what active users would see and is generally more stable than the development environment. 3rd party systems may be active at this stage to fully simulate the user experience.
Production Environment
This is the version of the system that users see and interact with. It contains live data and outages are considered critical. No changes should be made directly to this environment without first going through a review and testing process.
Scrum
Scrum is one of the most popular methodologies that uses Agile principles. In this methodology, the team commits to a set amount of work in fixed periods of time called “sprints”. The work is then evaluated, and a new set of work is chosen for the next sprint based on the results of the previous one.
Version Control
Technology used to update the code base in a controlled and reversable way. Code bases that are version controlled can easily be “rolled back” to a previous version if a mistake is made. Virtually all modern code repository tools will use some form of version control to protect the code base.
Automated Testing
Software systems are wildly complex and contain too much functionality to test manually. To deal with this, engineers write small pieces of code that test the functionality of the code that comprises the system. These tests run periodically and let the engineers know if any of the system code changed in a way that broke functionality. When that happens, a report will tell the engineers where the failure happened which lets the system be fixed much faster. Below are some examples of specific types of automated tests.
Unit Tests
Tests designed to validate that individual “units” of code still run properly. For example, a unit test may validate “XYZ unit of code always generates an even number”.
Integration Tests
These tests ensure that large modules of functionally within the system behave properly when combined. For example, an integration test may validate “Module X and Module Y do not product errors when run together”.
End-To-End (e2e) Tests
These tests simulate a user in the system by testing functionality from the standpoint of the UI. While these tests more accurately represent the real-world usage of the system, they are more expensive to build, slower to run, and more difficult to change. Because of this, engineers may choose to use them sparingly. An end-to-end test may validate “When the user clicks on X page element, the page navigates to Y page”.
Repository
A place where all the code in the application is stored and updated. Typically, this is cloud hosted and accessible anywhere.
Sprint
A sprint is the period of time in which a team will work on a set amount of work. Sprints periods are anywhere from 1-4 weeks, however 1-2 week sprints are generally considered the most productive.
Test Driven Development (TDD)
Test driven development is a coding practice in which engineers write the automated tests before writing the functionality. As the functionality is being written, the automated tests will continually tell the engineer if the new code is correct. This is generally considered a more advanced technique but results in extremely well written and tested code.
Language
The way in which individual lines of code are written. Similar to traditional human languages.
Continuous Integration and Continuous Development (CI/CD)
CI/CD is a series of automations and activities designed to move new pieces of functionality through a “pipeline” of validation and testing before ultimately being deployed for users to experience. The CI/CD process is one of the primary concerns of a DevOps practitioner.
Framework
A collection of pre-build functionality, written in a specific language, that encourages developers to build a system using known patterns. For example, applications using the Angular framework are written in the Typescript language. The Angular framework provides pre-built tools, written in Typescript, that only work properly if used the way the Angular framework developers intend for them to be used. Frameworks allow teams to move much faster, but occasionally present development challenges if the project calls for functionality that the framework does not support.
Monitoring
All systems experience errors, regardless of how much automated testing is done. When these errors happen in production the system needs a way of reporting what went wrong, when it went wrong, and who was affected to the development team. Monitoring software is installed within the system code to generate these reports and send out alerts when critical errors happen.
Tech Stack
The “stack” refers to the collection of technology used in each of the layers of the application. An example of a tech stack would be “Angular, .NET Core, and SQL” which means that the front end of the application would be written in Angular, the API/middle layer would use the .NET Core framework, and the database would be a SQL database.
Front End Layer
The “front end” refers to the technology used to produce the part of the system the user sees and interacts with. This can refer to website tech or mobile app tech.
Middle Layer
The middle layer or middle tier is the part of the application that acts as the “brain” of the system. It makes decisions about what information is sent to the front end, how information is transformed, and what information is sent to the database.
Storage Layer
This layer houses data long term. When a user makes a request via the front end, the middle layer interprets this request and retrieves data from this layer.
Key questions for potential partners
Questions are an absolutely vital part of the process. With the success of your project riding on both parties understanding of each other’s needs and capabilities, the only “bad” question is the one not asked. We’ve provided some example questions to get a feel for your partner’s capabilities, but we encourage you to think of more and ask away.
“Will I have access to the team’s planning tools?”
Teams should be using some sort of centralized place for organizing the current work (essentially a group TO DO list), and you should have access to it. You are paying a lot of money and you deserve to have work visible to you.
“How will I check the quality of the work during development?”
Again, work needs to be visible. If you do not have a way to test or view the system than you cannot confirm that the correct work is being done. Rewrites are expensive. Its your job to provide rapid and frequent feedback, and it’s the development team’s job to make it easy for you to see your system. Most firms should create a test environment for you to play around with as the system is built.
“Will I have access to the repository?”
Its your code. You paid for it, you own it, and you should have access to it. Larger, more established firms may simply write into the contract that you own all the code and provide access as needed. However, if you’re dealing with freelance engineers, or otherwise less established businesses, always ask for admin access to the repository so that you can remove users and retain your code.
“Who owns the IP of the code generated, and is it specified in the contract?”
This is a highly complex issue that will likely require further research on your part. However, in general you will want to make sure that the code used in your system is either written by your team or open source and legal to use free of charge. You will also need to make sure that all code written by your development team is completely and totally owned by you forever.
“What is your preferred tech stack?”
They should be able to answer what their preference is, as well as if they’re able to use other technology beyond their favorites. Do your research on the technologies they use and try to avoid niche languages and frameworks that may hurt you in the future.
“What is your automated testing process like?”
At a minimum they should use unit tests and LOTS of them. The more they can speak on testing the better. Companies that use unit, integration, and end to end testing while practicing test driven development will likely produce extremely high-quality code but will be more expensive than other companies. In general, automated testing slows development up front, but saves huge amounts of money long term. If your project is quick and not very complex, you’ll likely be ok without much automated testing. If you intend to build large, enterprise system, testing is a must, and your development partner needs to be capable of building those tests.
“What is your CI/CD process like?”
Ideally the process will involve a test or staging environment that is not public. Releases should be frequent and automated tests should run as part of this process. This process should also provide a quick way to revert back to previous versions of the system in the event of a critical error making it into the production code.
“What is your work methodology?”
Good processes are arguably one of the most important determining factors in the success of a team. If a development partner cannot accurately describe the process by which the team completes work, you can bet that development will be slow and poor quality. Amongst defined development methodologies, Agile centric methodologies have been proven to be the most effective as they promote strong communication, frequent evaluation, and rapid adaptation to new requirements.
Did you get all that?
This is a massive topic and unfortunately this ridiculously long blog post doesn’t even scratch the surface. However, we hope that this information was thought provoking enough to serve as a starting point on your journey, and to help you feel more confident and more capable of working with a team.
At Sigao our mission has always, and will always, be to leave our partners better off than before they met us. If you have any questions about this topic, feel free to comment below or give us a shout directly.
Refactoring legacy code can be daunting. While trial by fire is a great way to learn most kinds of programming, it doesn’t leave a lot of room for getting better at it (at least not quickly).
When trying to hit a deadline it is often difficult to take a step back, try different techniques, and learn a few keyboard strokes to automate some of the more mundane tasks. Coding katas are one way we can hone our craft outside the pressure of deadlines and our day jobs. It’s even better if your day job encourages spending a little time now and then to improve.
What is a coding kata?
The term “coding kata” comes from one of my favorite programming books: The Pragmatic Programmer. “Kata” is a word borrowed from martial arts that describes a movement, or series of movements, repeated to perfect some technique. Applied to programming, it is an exercise that is repeated to perfect some skill.
Typically, these exercises are small enough to be executed in a short amount of time and can be solved easily. Once a problem and its solution are known, the programmer can then focus on technique:
learning keyboard shortcuts to increase speed
applying design patterns to make code easier to change
using test-driven development to reduce regression rates and produce cleaner code
etc.
Finding a coding kata to try is just a google search away. Another place you might start is here: http://codekata.com/
What is special about the Gilded Rose kata?
Most coding katas give you the description of a problem and maybe some other goals to make it more interesting. You choose the tools you like and start practicing.
The Gilded Rose, however, starts by giving you some code. It isn’t a clean code. In fact, if you think that it is good code I would genuinely like to hear your thoughts on what I’m missing. The poor quality of the code is part of the challenge.
Your mission, if you choose to accept it, is to clean the code up such that it is easier to understand. Having done that, put your new design to the test by adding a new feature to the code. If it is easy to add the new code, congratulations, you have succeeded. It need not stop at success, though. The next step might be to minimize the time it takes you to complete the exercise. Finding tweaks, like keyboard shortcuts or better design patterns, could build a technique that helps you to execute more effectively and efficiently in your day job when the stakes are higher.
There are countless ways to work this kata. It is my go-to when I’m trying to learn a new language, or refresh myself on a language I haven’t used in a while. I also use it in my coaching gigs because it lets me easily demonstrate a number of concepts in just a few hours:
Automated testing
Pinning tests
Test-driven development
Code coverage
Design patterns
Factory method pattern
Null Object pattern
Strategy pattern
Template Method pattern
Design principles
Single Responsibility Principle
Open Closed Principle
Refactoring techniques
Extract method
Extract class
Extract interface
Pair Programming
… and more
By the way, this kata is also a great way to try out a lot of different agile development techniques.
How do I get started?
All you need to get started is the Gilded Rose source code in a language of your choice, the kata description/requirements, and your favorite development tools.
Emily Bache has a Git repository that contains the code for Gilded Rose in many different languages: https://github.com/emilybache/GildedRose-Refactoring-Kata. It also has a requirements document describing the existing behaviors and desired new functionality.
Welcome to AgileKit – an interconnected framework of Agile tools designed by agile coaches, scrum masters, and product owners to support Agile teams in product planning and construction.
AgileKit is an internal project we’ve been developing over the past 2 months. While developing core concepts for the applications as a whole, we started to notice the same ideas pop up:
Simple
Easy
Functional
When it came time to Brand, we took these same concepts into account.
First, we started with the color: “blue.” Yes, we understand the cliché of the color blue and tech. However, blue is the favorite color of most, if not all people.
“It’s nature’s color for water and sky but is rarely found in fruits and vegetables. Today, blue is embraced as the color of heaven and authority, denim jeans and corporate logos. [However, blue] has more complex and contradictory meanings than any other color. These can be easily explained by pinpointing by the specific shade of blue. Most blues convey a sense of trust, loyalty, cleanliness, and understanding.”
After searching through what seemed like a never-ending wasteland of blue’s, we finally found – the one. #296BFF embodies what we hope to convey about AgileKit: constant inspiration, serenity, and dependability.
Once the color was decided, next came the last and arguably most challenging aspect, construction of the mark itself.
We went through a handful of ideas before the final mark really started to take shape.
First, we started with curly brackets and an icon of sorts inside. Then, we tried various versions of combining ‘ak’ into useful shapes – that went into a steep free fall ending with the genuine realization that it just wasn’t going to work. But that’s ok – We went back to the drawing board and decided a more stylized, and fluid shape was going to fit the AgileKit brand best.
Probably couldn’t explain just how the concept came about, it was more of a vague idea, out there in the ether. However, It started with this illustration of a sprint cycle.
And so it began.
The original idea was to have swooping lines to indicate direction. After several revisions, we noticed the mark moving further and further away from the core idea and beginning to get too messily detailed. Therefore, we decided to take several steps back and add more curves, instead of sharp lines – and thus, the final mark was created.
The mark’s interpretation is up to the viewer, it could be a water drop, a planet, a blob, a blob with another blob, or our personal favorite – a very stylized version of a sprint cycle. Our hope is, regardless of what you actually see, you know it’s the simple, easy, and dependable software of AgileKit.
When building large-scale Angular applications, most people eventually need to provide their application with environment-specific variables, which doesn’t seem like a very big deal on the surface. After all, Angular provides us with the “environment.ts” file, right?
It should be as easy as filling in your environment settings and then using the environment variable throughout the site, but this method introduces a level of uncertainty into the build process that may not be acceptable for all applications.
This uncertainty comes primarily from the need to rebuild the application before those new variables are accessible. For example, when changing from a Dev environment to a Test environment, the build process is at the mercy of hundreds of code packages that may or may not have updated since the last environment promotion. This can cause time-consuming build errors that aren’t even related to the quality of your code.
In some instances, it may be possible to avoid these errors by locking down dependencies with something like “npm shrinkwrap.” However, due to the complexity of the Angular CLI build process, this approach still allows for the potential of different outputs. Even if you manage to get consistent outputs, it’s still time-consuming to constantly rebuild the application in a build pipeline that could potentially get backed up from rapid promotions.
The Solution
Before the application loads, retrieve a CI/CD generated settings file from the server, which allows you to make sure that an unchanged code base can get up to date settings no matter the environment. Here’s how our process works:
Create the configuration service
First, we create a service in one of your top-level Angular modules, typically the App Module or, if applicable, the Core Module. You can also create this service in any non-lazy loaded module that provides services to the application.
@Injectable({
providedIn: 'root',
})
export class AppConfigService {
public settings: AppSettings;
get WebUrl() {
return location.protocol + '//' + window.location.host + '/';
}
constructor() {}
public load() {
return new Promise((resolve, reject) => {
const self = this;
const xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function () {
if (this.readyState === 4 && this.status === 200) {
const data = JSON.parse(this.responseText);
const jsonConvert = new JsonConvert();
self.settings = jsonConvert.deserializeObject(data.BaseSettings, AppSettings);
resolve(true);
}
if (this.status === 404) {
reject('Server cannot find Appsettings.js file');
}
};
xhttp.open('GET', 'appSettings.json', true);
xhttp.send();
}).catch(error => {
console.error(error);
});
}
}
The “load” function is where we get our settings. Unfortunately, we can’t use Angular’s built in HttpClient because it forms a circular reference with our authentication service, but depending on your project structure, you may be able to simplify this request with built-in Http functionality.
After we receive the data, we use an external library (Json2Typescript) to convert the settings JSON into a typescript class so we can include helper functions if necessary. We then assign this object to the “settings” property on this service to be used elsewhere.
Create the appSettings.json file
This file structure is entirely up to you and your preferred CI/CD tool, but here’s an example for reference.
Angular needs to be informed specifically about which files are assets so it includes them in the build process. We place our appSettings.json in the root “src” folder of our web application. Because of this, our assets list inside of the angular.json file looks like this:
If you place the settings in a different folder, you’ll need to link directly the file, rather than the folder location (e.g., “src/assets/appSettings.json” rather than “src/assets/”).
Tell the app to load settings before launch
The last step on the client side is to make sure the application knows to load the settings before anything else initializes. This is done through Angular’s built-in APP_INITIALIZER function. Below is an example of our core module using the APP_INITIALIZER to load settings.
Your factory function should return a function that returns a promise. As you can see, we’ve injected our App Config service and returned our “load” function, which will return a promise. Once that is completed the rest of the application will be allowed to load, and the configuration service, with settings, will be available throughout the application.
Configure the build service
At this point, your angular application should be set. The only thing left to do is configure the release service to change the appSettings.json for every environment, and your application should retrieve them properly when it starts. We use Azure DevOps build/release to update the appSettings.json file, but you can use any release-management tool that supports updating json files.
I’m excited to share that a project we worked on, the TexasYouth2Adult Transition Tool, with BridgingApps is nearing launch.
Texas Youth2Adult is a resource for young adults with special health care needs (and their families) as they transition from youth to adulthood. This is an important program that will help a number of families in Texas, and BridgingApps hopes it will eventually expand to other states.
If you’re interested (or if you know someone who would be), you can sign up for updates on their site.
Sigao in the last planning session for TY2A
BridgingApps, part of the Easter Seals Greater Houston, focuses on helping children and adults with disabilities reach their highest levels of physical and cognitive development by providing access to educational and therapeutic tools that allow parents, teachers, and therapists to effectively use mobile devices and apps to target and improve individual skill development.
It’s a joy to work with an organization that’s truly making a difference in peoples’ lives, and we’re happy to congratulate BridgingApps on their pending launch.
I’m excited to announce that we have an amazing new Dynamics 365 client. We were contacted this last week from a representative of none other than Santa Claus himself. It seems that Old Saint Nick is a bit of a tech nerd and has really wanted to streamline his mail room floor operations. Recently Santa and Mrs. Claus came across WordPress and thought it would be a great platform for them to use to build a letter writing system to help more children to easily send letters to Santa.
I’m excited to have the opportunity to speak at SQLSaturday #652 in Atlanta, GA on July 15, 2017. SQLSaturday #652 will be my fourth SQLSaturday to speak at, and I’m loving getting engaged with the SQL community through SQLSaturday and PASS (a not-for-profit organization that supports data professionals who use the Microsoft Data Platform). SQLSaturday Atlanta is a large event with over 60 sessions and a host of wonderful speakers from all over. Topics will range from the administration and maintenance of SQL server to indexing and advanced T-SQL all the way to topics like mine, CosmosDB and NoSQL databases.
In this post, I highlight the first Sigao Studios Academy video, a new YouTube offering from Sigao Studios. In this video, I summarize CosmosDB’s Graph API. CosmosDB uses Apache’s TinkerPop and its Gremlin language to add graph database functionality to its massively scalable data as a service offering. TinkerPop can be found in a host of other graph systems including Blazegraph, ChronoGraph, Hadoop Giraph and others. Its powerful graph traversal language, Gremlin, allows you to quickly traverse a database and derive information from the underlying data.
Here at Sigao, we’ve been working with the Microsoft’s Dynamics platform for quite some time. We’ve often had situations where we have some custom action that we want to use to activate one of our custom plugins. Here, I’ll walk you through how to trigger one of your plugins automatically as a user progresses through a business process flow. The overall flow of this process is described below.
In the final post of this series, we will integrate Azure Search into our DocumentDB collection and allow users to search our Jeopardy Questions in our app.
