Welcome!

AppDynamics the World Leader in APM and DevOps

AppDynamics Blog

Subscribe to AppDynamics Blog: eMailAlertsEmail Alerts
Get AppDynamics Blog via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

Before PHP Performance, Looking at Your Software Process

image_pdfimage_print

In an effort to optimize your application performance you benchmark and profile your code, built a solid testing environment, collect key metrics, the whole nine yards. Yet, a growing realization eventually dawns on you that your team isn’t pushing out new features as fast as they used to without placing the performance of your app in jeopardy. You’ve hit a tipping point and are neck-deep in a backlog-pile-up and can’t evolve your software as fast as you did. You miss those good ‘ol days when new features were being pushed out at almost every iteration, bugs were few and far in between, the company couldn’t keep up with how fast your team was developing and life was good.

The answer may be simpler than you think as the solution to reaching maximum development velocity probably lies in your development process itself. Your team velocity should evolve to include focusing on a combination of new features, bug resolution and application optimizations. Striking the right balance among all these variables will help you reach your maximum effectiveness.

There are a number of things that you need to look at and evaluate, such as:

Project Management Methodology

Software lifecycle management patterns have been observed and summarized into best practices but similar to software design patterns there is no perfect solution that applies to every situation. The implementation of a methodology can (and probably should) be tailored to best fit the personality of your team.

An agile shop may implement an Agile process, keep track of velocity, estimate story points and have the art of estimating down to a science. But where do the lines of effectiveness and efficiency cross? You may be extremely efficient at implementing your process but you’re so caught up with following the “rules” that you’re losing effectiveness.

That’s right, effectiveness and efficiency are not the same thing.

Of course certain rules and checkpoints are necessary: having code-review, ensuring proper builds are run before deployment, etc. You should ask yourself whether having checkpoints are necessary or are they hindering progress? You should also explore whether you’re lacking certain processes that may bring some control to the chaos. But at some point you’ll need to determine for yourself whether you have too many checkpoints or not enough.

Building Your Team

You need to ensure that your development team is correct for your project. This means you have both the right skills as well as the right size.

Understaffing a project leaves you struggling to get everything done in time, with everyone pulling long hours and getting burned out. Too many people can be just as bad of a metric. Not only will people feel left out, feeling like they can’t contribute, but they may find themselves poking at pieces of the code in their spare time that really didn’t need touched. The team will lose focus, individuals will have their moral level drop, and the entire team dynamic will suffer.

It’s also just as important to make sure that you have the right mix of skills to go along with this. Do you need PHP experts? Dedicated JavaScript developers? HTML/CSS Wizards? DevOps people to integrate tightly with the systems? Or do a few general purpose jack-of-all-trade types fit your project best.

There really is no right answer here; there is only a right answer per project. That answer will constantly change as the project itself evolves as well, and it takes a good manager to be on top of this.
This project is going to need a lot of overtime

Speaking of building teams, check out AppDynamics openings here!

Budget

Going hand-in-hand with building out your team, you (unfortunately) always have to think of your budget as well. You need to make sure from the very beginning that you have enough budget allocated. There is nothing worse than getting halfway through a project and suddenly having to shelter it because there’s no money left.

Beware of of feature creep! When scoping a software you’ll need to stay disciplined in keeping true to the original MVP (minimum viable product). Once the minimum feature-set has been designed and approved, keep true to that roadmap. Of course every feature can always be improved! Of course you’ll think of new ways to do things! But in order to get a product out the door, you need to learn when you draw the line and call for a feature-freeze. Otherwise, you’ll burn right through your budget, miss critical deadlines and turn your project into a speeding train without brakes. Remember, done is better than perfect.

Don’t extremely over-budget either. Having padding is a smart idea, but your company probably could have used that extra budget in better ways. It leads you down a path of over-staffing, and running into the same issues we mentioned above.

Using Version Control

Let’s focus back to the application itself. At the very top of that list, is the need to use Version Control. To many of us it seems like such an obvious thing, yet it’s amazing how many people still haven’t seen the need for this.

Whether you are a team of one, or a team of 1000, you really need to be using some form of version control. Beyond the obvious need to “find that code that was blown away two days ago”, the abilities provided by the version control systems to manage having multiple developers all working together, on the same project, and committing code while the software ensures that there are no issues, is simply invaluable.

There are plenty of VCS options out there, with Git probably being the most popular at the moment. But there are a slew of others such as CVS, Mercurial, Bazaar, SourceSafe and more.

You need to find a version-control workflow that best match how your team is (or will be) working together. For example Git is designed around the idea of extremely distributed workload, with lots of developers working independently of each other, throwing away lots of local code that they only kept temporarily, and committing back just the final pieces that they are ready with.

Tracking Issues/Bugs

It’s a fact of life; your software is going to have bugs. When they are found you are going to need a good solution to allow you to store the details of the bug, assign it off to a developer to fix, and then track the bug as it’s fixed and verified.

At the same time, most bug tracking software is designed to also allow you to track your new product features and enhancements as well. If you are a sole developer on a project, using software such as this can be crucial to remembering all the moving parts and where you are trying to go. If you are running a large team, then it’s extremely important to make sure that issues are captured, shared with the team, and that it’s clear who is working on it. There is nothing worse then finding out that the last two days of work you just did on a bug, was just solved by another developer.

There are lots of issue/ticket tracking software solutions out there. These range from software packages such as Trac or JIRA, to hosted solutions such as provided by GitHub or Unfuddle. There are simply too many options to list. The best option for your team is one that they will use. Check out the options that are available and find what matches your development process best.
iStock_000003180321_Small

Avoiding Code Debt

Hopefully you are familiar with the concept of code debt. It’s where you have code in your system that is subpar, that you need to fix before you can actually add new features (or where you have to work-around it in order to do anything). Code debt can be created by bad architecture designs (even if they were good decisions at the time), or by simply having cases where a programmer chooses to create sub-par code in the first place, saying: “I’ll come back and fix this later,” just to get a feature out the door more quickly. An easy way to estimate your code-debt is by simply searching your entire code-base for the strong “// todo”. You’d be surprised how many times programmers know their code will need to be re-factored before they’re even finished writing it.

The more code debt that you build up, the longer it takes you to complete any task, be that adding a new feature, or fixing an old bug. Not only that but there’s a good chance that any case of code debt existing is also a potential source of performance issues in your software product.

One common solution to attempt to reduce code debt (though there is no magic bullet) is the use of Agile development processes. In Agile development you aren’t locked to a huge architecture decision in the beginning, but you build the software in small pieces, one at a time, modifying the product as you go. With a proper Agile environment, you shouldn’t ever push off some bad code to “Get a feature out quickly,” nor have the problem of realizing that a massive architecture mistake was made too late. As the whole time you are developing it is a constant iterative process, where the entire system is always getting just slightly better.

Deployment Process & Rollbacks

Of course you also need to have a solid system for handling deploying your code out to your server(s). This is a highly “personal” thing. There are solutions as simple as a small script that checks out code, zips it, and uploads it to full-blown and very complicated systems like Capistrano.

There are two important things here for you to make sure that your team has covered. First of all, you want it to be as easy as possible to deploy code – Optimally you want to be doing this as often as possible, with as small of deployments as possible so that there is less code movement per release. A deployment shouldn’t involve having the entire team on call and an hour-long process. A single script should be able to run that makes all the magic happen.

Secondly, the opposite of deployment is just as (if not more) important. You need to be able to rollback a deployment as well. We mentioned before how bugs are inevitable? Well, that applies not only to small bugs in existing code, but to show-stopping bugs upon deployment. Hopefully this won’t happen to you, but you need to be prepared when it does. Have just as simple of a way to rollback a deployment, as it was for you to push it live in the first place.

That one fact will save you countless hours, countless issues, and keep the hair on your head.
Presentation of web application lifecycle

Wrapping it Up

Well, that’s a tour of some of the biggest process items for your team to think about. As we continue this series of posts we will cover some of this things in more detail, as well as really start getting into various performance issues that will happen in your code itself.

Start solving your PHP performance problems, start a FREE trial of AppDynamics today!

The post Before PHP Performance, Looking at Your Software Process written by appeared first on Application Performance Monitoring Blog from AppDynamics.

Read the original blog entry...

More Stories By AppDynamics Blog

In high-production environments where release cycles are measured in hours or minutes — not days or weeks — there's little room for mistakes and no room for confusion. Everyone has to understand what's happening, in real time, and have the means to do whatever is necessary to keep applications up and running optimally.

DevOps is a high-stakes world, but done well, it delivers the agility and performance to significantly impact business competitiveness.