Subscribe: Matt Watson
Added By: Feedage Forager Feedage Grade B rated
Language: English
access  application  developers  development  log  mwatson archive  problems  product  production  server  stackify  support  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Matt Watson

Matt Watson

Software developer, product visionary, and master of #dadops

Copyright: Matt Watson

ASP.NET Performance Tracking Tools

Sun, 06 Dec 2015 15:50:07 GMT

Originally posted on:

Stackify just published a great blog post about all the different ways to track the performance of your ASP.NET apps. Including code profiling, IIS logs, application performance management, glimpse, RUM, and more!

"One of the best things about being a .NET developer is all the amazing development tools that can make your life easier. This blog post is a list of the various types of tools at your disposal for finding and optimizing performance problems. Depending on the task, some of these tools will be much better than the others."


DevOps – A Valentine’s Day Fairy Tale

Wed, 13 Feb 2013 21:39:10 GMT

Originally posted on: upon a time two people from different sides of the tracks met and fell in love. Never before had the two people found another person who so perfectly complemented them. Society tried to keep them apart – “It’s just not how things are done,” they’d say. But times were changing, and this sort of pairing was becoming more socially acceptable.They met at the perfect time.Ops had grown tired of the day to day grind of solving other people’s problems. Enough was enough and she needed a change in her life.  A perfectionist and taskmaster to the highest degree, she tended to be very controlling and possessive in relationships. It became more about commands than conversation, making life miserable for both parties. She began to realize she hated change, and felt like she spent most of her time saying “No.” It was time to open up and begin to share to make a relationship work.Dev, on the other hand, was beginning to mature (a little late in the game, as guys seem to) and trying to find some direction. He had grown tired of communication breakdowns in relationships – angry phone calls in the middle of the night, playing the blame game, and his inability to meet halfway on anything. He began to realize most of those angry phone calls came as a result of making impulsive decisions without considering how they would impact others. His bad decisions commonly led to performance problems and created a mess for his partners. Dev wanted to more actively seek out everything that makes a healthy relationship work.The timing was right for a match made in heaven. Dev and Ops openly working and living side by side to make sure both contributed equally to making their relationship work. Ops realized she didn’t have to be so controlling if she and Dev could build trust between one another. Dev realized that he caused fewer fights if he involved Ops in decisions about the future, since those decisions impacted both of them. It was a growing process that caused a lot of rapid and sudden change. Although, like most relationships, they knew it was important to not move too fast, no matter how good it felt.Dev and Ops dated for about four years before they decided to get married. Now they will be living together and sharing so much more; will their relationship last? How will it need to change to support the additional closeness? But they aren’t worried, they know it is true love and will do whatever it takes to make it work. Relationships are always hard, and they know they can solve most of their problems with a reboot, hotfix, or patch cable.Will you accept their forbidden love?7 Reasons the DevOps Relationship is Built to LastFaster development and deployment cycles (but don’t move too fast!)Stronger and more flexible automation with deployment task repeatabilityLowers the risk and stress of a product deployment by making development more iterative, so small changes are made all the time instead of large changes every so oftenImproves interaction and communication between the two parties to keep both sides in the loop and activeAids in standardizing all development environmentsDevOps dramatically simplifies application support because everyone has a better view of the big picture.Improves application testing and troubleshooting [...]

The Golden Rule of Programming

Fri, 18 Jan 2013 13:13:56 GMT

Originally posted on: published on is one particular issue that seems to be the root of most bugs in software programs. I see it over and over and over. Like most programmers, it has caused me heartburn since the day I started programming. So I have worked hard to make sure that my code never breaks my golden rule. So now I remind my development team every chance I get to also follow what I call the golden rule of programming. I think every new programmer needs a tatoo that says it.So what is the golden rule of programming?"If it can be null, it will be null"Null reference type errors are responsible for a good percentage of all application bugs. They are usually very simple problems. Typically caused by not adding additional logic to ensure that objects have valid values before using them.How about some simple examples of null values causing problems?Here is a classic example below. A string variable passed in to a method is used before ensuring it isn't null. KA-BOOM!public void DoSomething(string text) { if (text.ToUpper() == "Hello World") { //do something } }One of the most common causes is settings, database calls, or API type calls not returning expected values. For example, you add a new field to your database and don't populate default values for every record. Randomly records get queried and the code didn't account for that new field being null. KA-BOOM!The good news is that a lot of null reference errors can be avoided by adding additional logic and code to ensure objects are not null before trying to use them. Developers should always assume that everything is FUBAR and be very defensive in their code. Pretend every database call is going to fail, every field is going to have messed up data in it.Some tips to prevent null reference exceptions:Initialize variables with valid values.If a variable can be null, then check for null and handle it appropriatelyFor C# use the ?? operator with strings when appropriate. ex. (stringvar ?? "").ToUpper()If you follow my golden rule, I promise you will have far fewer bugs in your apps. Because if it can be null, it will be null! [...]

What is the Ops in DevOps?

Wed, 16 Jan 2013 16:43:29 GMT

Originally posted on: what does DevOps mean exactly? What is the Ops in DevOps?  Operations can mean a lot of things and even different things to different people. DevOps is becoming more and more popular but I also think a lot of people are confused to exactly what it is. So let’s make a list of all the things operations does and figure out what developers should be doing, and not doing.Operations responsilibitesIT buying decisionsInstallation of server hardware and OSConfiguration of servers, networks, storage, etcMonitoring of serversRespond to outagesSome other dutiesIT securityManaging phone systems, networkInternal help desk supportChange controlBackup and disaster recovery planningManage active directoryAsset trackingShared Development & Operations dutiesSoftware deploymentsApplication supportSome of these responsibilities have changed a lot in the last few years. Virtualization and the cloud have greatly simplified buying decisions, installation, and configuration. For example, nobody cares what kind of server we are going to buy anymore for a specific application. We buy great big ones, virtualize them, and just carve out what we need and change it on the fly. Cloud hosting simplifies this even more by eliminiating the step of buying a great big server.So what part of the Ops should developers do?Be involved in selecting the application stackConfigure and deploy servers (potentially)Deploy their applicationsMonitor application and system healthRespond to applications problems as they arise.In my opinion, that is the lifecycle of DevOps. Select the application stack, build it, deploy it, support it. The developers basically own the stack from operating system and up. If you have 5 development teams working on different projects, it makes a lot of sense for each team to be responsible for all of these things from start to finish. Make the developers completely responsible for their own application. Operations can simply be responsible for the physical infrastructure that supports it.So what does the operations team do then?Manage the hardware infrastructureConfigure and monitor networkingEnforce policies around backup, DR, security, change control, etcAssist in monitoring the systemsManage active directoryAsset trackingOther non production application related tasksIf your IT department is small, one of your developers can easily handle all of these tasks. In larger companies though I’m sure this role will be around forever. But… If you are using cloud based hosting, do you need operations at all? If you are embracing the DevOps concept of developers owning the deployment and production support of their applications, and you are using cloud hosting, you could probably say you are doing NoOps in your data center. But you still need at least a help desk person in the office to support your internal desktops.DevOps to me is the concept of letting the operations team provide the hardware and letting the developers basically own everything from the OS up. Select the application stack, build it, deploy it, support it.What do you think developers should do or not do? [...]

Kauffman Foundation Selects Stackify to Present at Startup@Kauffman Demo Day

Fri, 09 Nov 2012 13:16:53 GMT

Originally posted on:

Stackify will join fellow Kansas City startups to kick off Global Entrepreneurship Week

On Monday, November 12, Stackify, a provider of tools that improve developers’ ability to support, manage and monitor their enterprise applications, will pitch its technology at the Startup@Kauffman Demo Day in Kansas City, Mo. Hosted by the Ewing Marion Kauffman Foundation, the event will mark the start of Global Entrepreneurship Week, the world’s largest celebration of innovators and job creators who launch startups.
Stackify was selected through a competitive process for a six-minute opportunity to pitch its new technology to investors at Demo Day. In his pitch, Stackify’s founder, Matt Watson, will discuss the current challenges DevOps teams face and reveal how Stackify is reinventing the way software developers provide application support.

In October, Stackify had successful appearances at two similar startup events. At Tech Cocktail’s Kansas City Mixer, the company was named “Hottest Kansas City Startup,” and it won free hosting service after pitching its solution at St. Louis, Mo.’s Startup Connection.

“With less than a month until our public launch, events like Demo Day are giving Stackify the support and positioning we need to change the development community,” said Watson. “As a serial technology entrepreneur, I appreciate the Kauffman Foundation’s support of startup companies like Stackify. We’re thrilled to participate in Demo Day and Global Entrepreneurship Week activities.”

Scheduled to publicly launch in early December 2012, Stackify’s platform gives developers insights into their production applications, servers and databases. Stackify finally provides agile developers safe and secure remote access to look at log files, config files, server health and databases. This solution removes the bottleneck from managers and system administrators who, until now, are the only team members with access. Essentially, Stackify enables development teams to spend less time fixing bugs and more time creating products.

Currently in beta, Stackify has already been named a “Company to Watch” by Software Development Times, which called the startup “the next big thing.” Developers can register for a free Stackify account on
Founded in 2012, Stackify is a Kansas City-based software service provider that helps development teams troubleshoot application problems. Currently in beta, Stackify will be publicly available in December 2012, when agile developers will finally be able to provide agile support. The startup has already been recognized by Tech Cocktail as “Hottest Kansas City Startup” and was named a “Company to Watch” by Software Development Times. To learn more, visit and follow @stackify on Twitter.

Windows Server 2012 Enable RDP

Fri, 09 Nov 2012 13:10:29 GMT

Originally posted on:

After installing Windows Server 2012, one of the first things you likely need to do is enable RDP. Thanks to the Metro UI, things are a little different...

From command line go to SystemPropertiesRemote

Or right click bottom left corner and go to System, then Advanced System Settings, Remote tab

Here is a good article with more details if needed


Getting developers and support to work together

Tue, 16 Oct 2012 02:01:20 GMT

Originally posted on:

Agile development has ushered in the norm of rapid iterations and change within products. One of the biggest challenges for agile development is educating the rest of the company. 

At my last company our biggest challenge was trying to continually train 100 employees in our customer support and training departments. It's easy to write release notes and email them to everyone. But for complex software products, release notes are not usually enough detail. You really have to educate your employees on the WHO, WHAT, WHERE, WHY, WHEN of every item. If you don't do this, you end up with customer service people who know less about your product than your users do. Ever call a company and feel like you know more about their product than their customer service people do? Yeah. I'm talking about that problem.

WHO does the change effect?
WHAT was the actual change?
WHERE do I find the change in the product?
WHY was the change made? (It's hard to support something if you don't know why it was done.)
WHEN will the change be released?

One thing I want to stress is the importance of the WHY something was done. For customer support people to be really good at their job, they need to understand the product and how people use it. Knowing how to enable a feature is one thing. Knowing why someone would want to enable it, is a whole different thing and the difference in good customer service. Another challenge is getting support people to better test and document potential bugs before escalating them to development. Trying to fix bugs without examples is always fun... NOT. They might as well say "The sky is falling, please fix it!"

We need to over train the support staff about product changes and continually stress how they document and test potential product bugs. You also have to train the sales staff and the marketing team. Then there is updating sales materials, your website, product documentation and other items there are always out of date. Every product release causes this vicious circle of trying to educate the rest of the company about the changes.

Do we need to record a simple video explaining the changes and email it to everyone? Maybe we should  use a simple online training type app to help with this problem. Ultimately the struggle is taking the time to do the training, but it is time well spent. It may save you a lot of time answering questions and fixing bugs later. 

How do we efficiently transfer key product knowledge from developers and product owners to the rest of the company? How have you solved these issues at your company? 


Mozilla Persona to the login rescue?

Wed, 03 Oct 2012 03:36:28 GMT

Originally posted on:

A lot of websites now allow us to login or create accounts via OAuth or OpenID. We can use our Facebook, Twitter, Google, Windows Live account and others. The problem with a lot of these is we have to have allow the websites to then have access to our account and profile data that they shouldn't really have. 

Below is a Twitter authorization screen for example when signing in via Technorati. Now Technorati can follow new people, update my profile and post tweets? All I wanted to do was login to to comment on a post!


Mozilla has just released their new solution for this called Persona. First thought is oh great another solution! But they are actually providing something a little different and better. It is based on an email address and isn't linked to anything like our personal social networks or their information. Persona only exists to help with logging in to websites. No loose strings attached.

Persona is based on a new standard called BrowserID and you can read more about it here:
How BrowserID Works.  The goal is to integrate BrowserID in to the browser at a deeper level so no password entry is required at all. You can tell your web browser to just auto sign in for you. I am really hoping this takes off and will look at implementing it in current projects! I would recommend researching it and lets hope it or something like it becomes a wide spread reality in the future.

JavaScript Sucks. TypeScript Makes it Suck Less?

Tue, 02 Oct 2012 02:09:01 GMT

Originally posted on:

JavaScript Sucks. Yes, I said it. Microsoft's announcement of TypeScript got me thinking today. Is this a step in the right direction? It sounds like it fixes some of problems with JavaScript development. But is it really just duct tape and super glue for a programming model that needs to be replaced?

I have had a love hate relationship with JavaScript, like most developers who would prefer avoiding client side code. I started doing web development over 10 years ago and I have done some pretty cool stuff with JavaScript. It has came a long ways and is the universal standard these days for client side scripting in the web browser. Over the years the browsers have become much faster at processing JavaScript. Now people are even trying to use it on the server side via node. 

As an enterprise web application developer, I don't like any scripting or dynamic languages. I like code that compiles for lots of obvious reasons. JavaScript is messy to code with and lacks some modern programming features. There are compiling tools like Closure, jQuery, minify, coffee script, TypeScript and a bunch of other tools that have improved JavaScript. TypeScript looks like it will help with some of the problems like having variable types, compiling, and a better IDE to work with. We spend a lot of time trying to hack it to do things it was never really designed for. I don't think there is any point in debating in this post what the problems with JavaScript are. That isn't the point of the post and anyone who has used it has their own laundry list. (My favorite? Doing financial calculations in JavaScript is lots of fun.) The question is are we stuck with using JavaScript on the client side forever now? What alternatives do we have?

It is possible to program in Silverlight, Java or Flash and run that in the browser instead of JavaScript, but they all have their own problems and lack universal mobile support. I believe Microsoft's new TypeScript is a step forward for JavaScript, but I think we need to start planning to go a whole different direction. 10 years from now is JavaScript going to be the primary solution on the client side still? We need to start thinking about what replaces JavaScript... and I have no idea what the solution is. 


Production Access Denied! Who caused this rule anyways?

Sun, 23 Sep 2012 03:01:23 GMT

Originally posted on: of the biggest challenges for developers is getting access to production servers. In smaller dev teams of 5 or less people everyone usually has access. Then you hire developer #6, he messes something up in production... and now nobody has access. That is how it always starts. Just about every rule in life gets created this way. One person messes it up for the rest of us. Rules are then put in place to try and prevent it from happening again. Breaking the rules is in our nature. In this example it is for good cause and a necessity to support our applications and troubleshoot problems as they arise. So how do developers typically break the rules? Some create their own method to collect log files off servers so they can see them. Expensive log management programs can collect log files, but log files alone are not enough. Centralizing where important errors are logged to is common. Some lucky developers are given production server access by the IT operations team out of necessity. Wait. That's not fair to all developers and knowingly breaks the company rule!  When customers complain or the system is down, the rules go out the window. Commonly lead developers get production access because they are ultimately responsible for supporting the application and may be the only person who knows how to fix it. The problem with only giving lead developers production access is it doesn't scale from a support standpoint. Those key employees become the go to people to help solve application problems, but they also become a bottleneck. They end up spending up to half of their time every day helping resolve application defects, performance problems, or whatever the fire of the day is. This actually the last thing you want your lead developers doing. They should be working on something more strategic like major enhancements to the product. Having production access can actually be a curse if you are the guy stuck hunting down log files all day. Application defects are good tasks for junior developers. They can usually handle figuring out simple application problems. But nothing is worse than being a junior developer who can't figure out those problems and the back log of them grows and grows. Some of them require production server access to verify a deployment was done correctly, verify config settings, view log files, or maybe just restart an application. Since the junior developers don't have access, they end up bugging the developers who do have access or they track down a system admin to help. It can take hours or days to see server information that would take seconds or minutes if they had access of their own. It is very frustrating to the developer trying to solve the problem, the system admin being forced to help, and most importantly your customers who are not happy about the situation. This process is terribly inefficient. Production database access is also important for solving application problems, but presents a lot of risk if developers are given access. They could see data they shouldn't.  They could write queries on accident to update data, delete data, or merely select every record from every table and bring your database to its knees. Since most of the application we create are data driven, it can be very difficult to track down application bugs without access to the production databases.Besides it being against the rule, why don't all developers have access? Most of the time it comes down to security, change of control, lack of training, and other valid reasons. Developers have been known to tinker with different settings to try and solve a problem and in the process forget what they changed and made the problem worse. So it is a double edg[...]

Access Log Files

Sun, 16 Sep 2012 02:04:43 GMT

Originally posted on:

Some of the simplest things in life make all the difference. For a software developer who is trying to solve an application problem, being able to access log files, windows event viewer, and other details is priceless. But ironically enough, most developers aren't even given access to them. Developers have to escalate the issue to their manager or a system admin to retrieve the needed information. Some companies create workarounds to solve the problem or use third party solutions.

Home grown solution to access log files

Some companies roll their own solution to try and solve the problem. These solutions can be great but are not always real time, and don't account for the windows event viewer, config files, server health, and other information that is needed to fix bugs.

  • VPN or FTP access to log file folders
  • Create programs to collect log files and move them to a centralized server
  • Modify code to write log files to a centralized place

Expensive solution to access log files

Some companies buy expensive solutions like Splunk or other log management tools. But in a lot of cases that is overkill when all the developers need is the ability to just look at log files, not do analytics on them.

There has to be a better solution to access log files

Stackify recently came up with a perfect solution to the problem. Their software gives developers remote visibility to all the production servers without allowing them to remote desktop in to the machines. They can get real time access to log files, windows event viewer, config files, and other things that developers need. This allows the entire development team to be more involved in the process of solving application defects.

Check out their product to learn more

Agile Development Requires Agile Support

Mon, 10 Sep 2012 20:30:53 GMT

Originally posted on: development has become the standard methodology for application development. The days of long term planning with giant Gantt waterfall charts and detailed requirements is fading away. For years the product planning process frustrated product owners and businesses because no matter the plan, nothing ever went to plan. Agile development throws the detailed planning out the window and instead focuses on giving developers some basic requirements and pointing them in the right direction. Constant collaboration via quick iterations with the end users, product owners, and the development team helps ensure the project is done correctly.  The various agile development methodologies have helped greatly with creating products faster, but not without causing new problems. Complicated application deployments now occur weekly or monthly. Most of the products are web-based and deployed as a software service model. System performance and availability of these apps becomes mission critical. This is all much different from the old process of mailing new releases of client-server apps on CD once per quarter or year.The steady stream of new products and product enhancements puts a lot of pressure on IT operations to keep up with the software deployments and adding infrastructure capacity. The problem is most operations teams still move slowly thanks to change orders, documentation, procedures, testing and other processes. Operations can slow the process down and push back on the development team in some organizations. The DevOps movement is trying to solve some of these problems by integrating the development and operations teams more together. Rapid change introduces new problemsThe rapid product change ultimately creates some application problems along the way. Higher rates of change increase the likelihood of new application defects. Delivering applications as a software service also means that scalability of applications is critical. Development teams struggle to keep up with application defects and scalability concerns in their applications. Fixing application problems is a never ending job for agile development teams. Fixing problems before your customers do and fixing them quickly is critical. Most companies really struggle with this due to the divide between the development and operations groups. Fixing application problems typically requires querying databases, looking at log files, reviewing config files, reviewing error logs and other similar tasks. It becomes difficult to work on new features when your lead developers are working on defects from the last product version. Developers need more visibilityThe problem is most developers are not given access to see server and application information in the production environments. The operations team doesn’t trust giving all the developers the keys to the kingdom to log in to production and poke around the servers. The challenge is either give them no access, or potentially too much access. Those with access can still waste time figuring out the location of the application and how to connect to it over VPN. In addition, reproducing problems in test environments takes too much time and isn't always possible. System administrators spend a lot of time helping developers track down server information. Most companies give key developers access to all of the production resources so they can help resolve application defects. The problem is only those key people have access and they become a bottleneck. They end up spending 25-50% of their time on a daily basis trying to solve application issues because they are the only ones with access. These key employees’ time is [...]

Stackify Gives Devs a Crack at the Production Server

Sun, 02 Sep 2012 03:28:09 GMT

Originally posted on: published on on 7/9/2012 by David Rubinstein.It was one of those interviews where you get finished talking about a company’s product, and you wonder aloud, “Well, THAT makes sense! Why hasn’t anyone thought of that before?” Matt Watson, CEO of Kansas City, Mo.-based startup Stackify, was telling me that the 10-person company is getting ready to launch its product in August (it’s in beta now) that will give developers an app-centric look into production servers so they can support and troubleshoot apps and fix bugs. Of course, this hasn’t happened in the past because of the security concerns of IT administrators, and a decided lack of expertise on the part of developers. Stackify installs on a server and acts like a proxy for developers, collecting data about the environment, discovering all the applications, scanning for config file changes, and doing server monitoring. “We become the central point that developers can see everything they need to know about their applications,” he said. “Developers can look at the files that are deployed, and query databases in a safe way.”  In his words:“The big thing we’re hoping is just giving them (developers) visibility. Most companies want to hire the junior developers that they pay $50,000 a year right out of college to do application support and troubleshooting and fix bugs, but those people don’t have access to production servers to troubleshoot. It becomes very difficult for them to do their job, so they end up spending all of their day bugging the senior developers, the managers or the system administrators to track down this stuff, which creates a huge bottleneck. And so what we can do is give that visibility to those lower-level people so that they can do this work and free up the higher-level people so they can be working on the next big thing.”Stackify itself might just prove to be the next big thing. [...]

Stackify Aims to Put More ‘Dev’ in ‘DevOps’

Sun, 02 Sep 2012 03:25:16 GMT

Originally posted on: published on on 8/22/2012 by Keith Ward.The Kansas City-based startup wants to make it easier for developers to examine the network stack and find problems in code.The first part of “DevOps” is “Dev”. But according to Matt Watson, Devs aren’t connected enough with Ops, and it’s time that changed.He founded the startup company Stackify earlier this year to do something about it. Stackify gives developers unprecedented access to the IT side of the equation, Watson says, without putting additional burden on the system and network administrators who ultimately ensure the health of the environment.“We need a product designed for developers, with the goal of getting them more involved in operations and app support. Now, there’s next to nothing designed for developers,” Watson says. Stackify allows developers to search the network stack to troubleshoot problems in their software that might otherwise take days of coordination between development and IT teams to solve.Stackify allows developers to search log files, configuration files, databases and other infrastructure to locate errors. A key to this is that the developers are normally granted read-only access, soothing admin fears that developers will upload bad code to their servers.Implementation starts with data collection on the servers. Among the information gleaned is application discovery, server monitoring, file access, and other data collection, according to Stackify’s Web site. Watson confirmed that Stackify works seamlessly with virtualized environments as well.Although the data collection software must be installed on Windows servers, it can monitor both Windows and Linux servers. Once collection’s finished, developers have the kind of information they need, without causing heartburn for the IT staff.Stackify is a 100 percent cloud-based service. The company uses Windows Azure for hosting, a decision Watson’s happy with. With Azure, he says, “It’s nice to have all the dev tools like cache and table storage.” Although there have been a few glitches here and there with the service, it’s run very smoothly for the most part, he adds.Stackify is currently in a closed beta, with a public release scheduled for October. Watson says that pricing is expected to be $25 per month, per server, with volume discounts available. He adds that the target audience is companies with at least five developers.Watson founded Stackify after selling his last company, VinSolutions, to for “close to $150 million”, according to press accounts. Watson has since  founded the Watson Technology Group, which focuses on angel investing.About the Author: Keith Ward is the editor in chief of Visual Studio Magazine.Stackify provides safe and secure production servers access to developers via an application dashboard. [...]

Production Server Access - Development teams do not scale without it!

Fri, 22 Jun 2012 03:05:16 GMT

Originally posted on:

Recently I have been thinking about how development teams don't scale very well. The bigger a team and the product get, the more time the team spends fixing software bugs. This means they spend more time doing troubleshooting and debugging as the grow. The problem is that since developers don't typically have access to production servers, there is a bottleneck in the process when doing production troubleshooting.

For a team that has 10 developers, I would guess than 0-2 of them have access to production servers. If that team grows to 20 people, it is probably the same 0-2 people that have production access still. This means that those 2 key people are a bottleneck and the team does not scale correctly as you add more resources. All those new developers want is to help track down and fix software bugs, but they don't have the visibility to do it. So they end up being less productive and frustrated because they really want to fix the problems. The people who do have production access end up spending too much of their time doing troubleshooting instead of working on new projects.

The solution is to remove the bottlenecks and get those people working on more important tasks. Stackify can solve this problem by giving all the developers read only access to production servers. This allows them to access the information they need to do troubleshooting on their own. The software provides remote server access via an application dashboard.