Wednesday, September 26, 2012

Common Agile Adoption Pitfalls


The ability to avoid common agile adoption pitfalls may seem daunting, but there’s a light at the end of the tunnel and your experience comes handy with agile adoption. There are some pitfalls as discussed below and we should take care of these points.

Focusing Only on Construction

You can realize the spirit of the Agile Manifesto through many approaches. Ironically, most of these approaches focus on one phase or discipline within the delivery life cycle; which goes against the spirit of lean, which advises to consider the whole.
Most approaches focus on the construction phase. Construction is typically a straightforward area to focus on when taking on an agile transformation, but if organizations only change the way they construct software, they can’t necessarily call themselves agile. The development teams could be humming along, delivering new working software every two weeks, but if the processes in Operations only allow for deployment every six months or if the Help Desk is unable to handle the churn or if customer take holders aren’t prepared to meet regularly, the organization isn’t realizing all the benefits agile can provide.

Becoming Agile Zombies

Organizations fall into the trap that if they attend a class and mandate a certain out-of-the-box (OOTB) process, that they are now agile. They train their teams to blindly follow and enforce the anointed process not considering which practices may need to change to meet their organization’s unique needs. Agile isn’t a prescribed process or set of practices; it’s a philosophy that can be supported by a practice and no two
Agile approaches are the same. One OOTB methodology that fulfills all needs doesn’t exist.

Improper Planning

That old adage, “If you fail to plan, plan to fail,” is really true. Planning is core to the success of any agile adoption.

Organizations should answer these questions:
      i.        Why do we want to be agile, and what benefits will agile provide?
     ii.        How will we achieve and measure agility?
    iii.        What cultural, technological or governance barriers exist, and how do we overcome them?

Without a plan that clearly shapes the initiative and includes addressing and resolving constraints to agility (for example, removing waterfall process checkpoints or getting support from other required entities), it is more difficult to shape the initiative, staff it, fund it, manage blockers and maintain continued executive sponsorship.

Excluding the Entire Organization

You can quickly short circuit an agile adoption by working in the vacuum of a single software or system delivery team. A single team can gain some benefit from agile, but to be truly successful, you need to look at the whole process around solution delivery. And many people are involved in that process. Agile should be a change in culture for the entire organization. Find champions in Operations, lines of business, product management, Marketing, and other functional areas to increase your success.

Lack of Executive Support

An effective agile adoption requires executive sponsorship at the highest level. This involvement means more than showing up at a kickoff meeting to say a few words. Without executive sponsorship supporting the overall initiative, the agile adoption is often doomed because agile initiatives require an upfront investment of resources and funding — two areas that executives typically control.

Going Too Fast

Moving to agile is very exciting, and it can be tempting to jump right in, pick a process, get some tools, and hit the ground running. Unfortunately, if a proper roadmap for coaching, process, and tooling isn’t outlined early in the adoption you can run into issues like the following:
      i.        No defined processes for dealing with multiple dependent or distributed teams
     ii.        Scalability issues with the core agile tools
    iii.        Extending the tool to support deployment, testing, or business collaboration

Insufficient Coaching

Because an agile adoption isn’t just a matter of a new delivery process, but is also major cultural shift, coaching is imperative. Developers don’t like change and many people like working in their own world. As a result, the concept of not only changing the way they develop, but adding the concept that now they have to work closely with five, six, or ten other people all the time can be downright horrifying.

A coach can work with these team members and help them through the early phases of agile adoption. Have you known of a teacher or coach that possessed a unique ability to inspire students to stretch their skills and perform at higher levels? Good agile coaching can have the same affect and make the difference between the success and failure of an agile adoption.

Retaining Traditional Governance

When an organization plans its agile adoption, it needs to evaluate all current processes and procedures and whether they inhibit or enhance agility. Existing traditional governance processes can be very difficult to change due to internal politics, company history, or fear that compliance mandates may be negatively impacted. Some common governance areas that are overlooked but can have dramatic impacts to agility are project funding, change control, and phase gates.

Skimping on Training

Organizations often see agile practice training, like coaching, as an area where they can save money, sending only a few key leads to learn the new process in hopes that they can train the rest of the organization while trying to implement the new approach. Agile involves a change in behavior and process. It is critical to send all team members to the appropriate training and provide them with ongoing training to reinforce agile values and update team members on processes that may have changed.

Skimping on Tooling

Agile tooling should support and automate an organization’s process. Ensuring all team members consistently use tools impacts the success of the project. If tools are used inconsistently, metrics may not correctly reflect the correct status, builds could be run incorrectly, and overall flow and quality issues result.

Ref: Agile for dummies

Enjoy Programming!!!

Friday, August 3, 2012

Cloud Computing & PHP


Now a days, there is a lot of discussion about cloud computing. All tell their stories, but not with the good reason of adopting it. The “cloud” is a pretty ambiguous term, and as such anything attached to it only makes the whole thing a little more ambiguous.

I feel the need to discuss term “cloud computing” for PHP developers and how they affect the coming era of development in the context of programming and deployment of code.

Let’s discuss about actual cloud-based computing services and why you need to be using them.

For PHP developers, the term “clod computing” focuses on two key areas as discussed below:
      i.        Cloud of third party web services constitutes the web stack.
     ii.        Cloud based hosting

Cloud of third party web services constitutes the web stack:


At the best of open source, there are so many contributions available to use third party web services.
The Amazon cloud is the best example to describe this part, actually; it has never been cheaper, faster and easier to setup, on-demand, geographically optimised web application environment. Amazon's cloud is one of the forerunners that has made these advantages possible.
Among Amazon's cloud-related offerings are EC2, S3 and CloudFront. EC2 (Elastic Compute Cloud) allows developers to start instances of servers (called Amazon Machine Images) and control them via a web-service interface. S3 provides storage on the cloud. Geographically optimised distribution of S3 objects is easily achieved via CloudFront.
A lot of stuff can be done with these cloud services. One can shoot off MapReduce processing with parallel Hadoop instances on EC2 or use it to run scripts and application that interacts with the enduser. Similarly, S3 can be used as a file storage for disk backups or as public image or video storage. The commodity pricing is a good deal and the natural growth in computing abundance provides a good downward weight on resource pricing.
Cloud based hosting:

Traditionally, if you wanted to host a site or app you would either get a shared hosting account somewhere, or get your own dedicated box (or many boxes). This generally works fine, but there are a lot of drawbacks to the so-called traditional way of doing things. We’ll get into this in a little bit, but for the moment we only need to know that these solutions involved actual physical servers. A dedicated server is just that, a dedicated piece of hardware for you to use… shared hosting is similar in the fact that you’re merely a tenant on a dedicated server (you could relate it to renting an apartment vs. owning a home).
Anyway, cloud computing is essentially the same as dedicated hosting, except for one very important distinction: you’re not using a physical server, your server is virtualized. That’s it, it’s really that simple! However, this simplicity has a lot of very important benefits that lead it to beat the hell out of any traditional hosting situation.
It also has one very significant draw-back as well if we talk about deploying code. To deploy code at cloud hosting, you are supposed to have good hands to handle LAMP stack. I believe, this is not a rocket science and every PHP developer must know the core of LAMP stack. No need to worry, there are lot of tutorials available online which helps you to deploy code at clod hosting and most of these tutorials are from the hosting providers itself.

Enjoy Programming!!!


Tuesday, July 31, 2012

Quote

"Before you answer a question, engage the brain before you engage your mouth."

Monday, July 16, 2012

Apache - A web server

A web server's job is basically to accept requests from clients and send responses to those requests. A web server gets a URL, translates it to a filename (for static requests), and sends that file back over the internet from the local disk, or it translates it to a program name (for dynamic requests), executes it, and then sends the output of that program back over the internet to the requesting party. If for any reason, the web server was not able to process and complete the request, it instead returns an error message. The word, web server, can refer to the machine (computer/hardware) itself, or the software that receives requests and sends out responses.
Popular web server - Why?

  • It is free to download and install.
  • It is open source: the source code is visible to anyone and everyone, which basically enables anyone (who can rise up to the challenge) to adjust the code, optimize it, and fix errors and security holes. People can add new features and write new modules.
  • It suits all needs: Apache can be used for small websites of one or two pages, or huge websites of hundreds and thousands of pages, serving millions of regular visitors each month. It can serve both static and dynamic content.

Functionality that you don't need or want can easily be removed.
The Apache HTTP server is a software (or program) that runs in the background under an appropriate operating system, which supports multi-tasking, and provides services to other applications that connect to it, such as client web browsers. It was first developed to work with Linux/Unix operating systems, but was later adapted to work under other systems, including Windows and Mac. The Apache binary running under UNIX is called HTTPd (short for HTTP daemon), and under win32 is called Apache.exe.

Apache's original core is fairly basic and contains a limited number of features. Its power rather comes from added functionality introduced through many modules that are written by programmers and can be installed to extend the server’s capabilities. To add a new module, all you need to do is install it and restart the Apache server. Functionality that you don’t need or want can easily be removed which is actually considered a good practice as it keeps the server small and light, starts faster, consumes less system resources and memory, and makes the server less prone to security holes. The Apache server also supports third party modules, some of which have been added to Apache 2 as permanent features. The Apache server very easily integrates with other open source applications, such as PHP and MySQL, making it even more powerful than it already is.

Web server
A web server in its simplest form is a computer with special software, and an internet connection that allows it to connect to other devices.

The Apache server offers a number of services that clients might make use of. These services are offered using various protocols through different ports, and include: hypertext transfer protocol (HTTP), typically through port 80, simple mail transfer protocol (SMTP), typically through port 25, domain name service (DNS) for mapping domain names to their corresponding IP addresses, genearlly through port 53, and file transfer protocol (FTP) for uploading and downloading files, usually through port 21.

Directories constitute Apache
As we know, Apache can be installed on a variety of operating systems. Regardless of the platform used, a hosted website will typically have four main directories: htdocs, conf, logs, cgi-bin.

htdocs is the default Apache web server document directory, meaning it is the public directory whose contents are usually available for clients connecting through the web. It contains all static pages and dynamic content to be served once an HTTP request for them is received. Since files and sub-directories under htdocs are available to the public, correct handling of file permissions is of great importance so as not to compromise the server’s safety and security.

conf is the directory where all server configuration files are located. Configuration files are basically plain text files where directives are added to control the web server’s behavior and functionality.

logs is the directory where server logs are kept, and includes Apache access logs and error logs. The Apache HTTP Server provides a variety of different mechanisms for logging everything that happens on it, from the initial request, through the URL mapping process, to the final resolution of the connection, including any errors that may have occurred in the process.

cgi-bin is the directory where CGI scripts are kept. The CGI (Common Gateway Interface) defines a way for a web server to interact with external content-generating programs, which are often referred to as CGI programs or CGI scripts. These are programs or shell scripts that are written to be executed by Apache on behalf of its clients.

Note:   It is important to note that the above discussed file and directory names (as well as locations) can differ from one server to another depending on the Apache flavor installed and the operating system it runs under. The roles though remain the same.

Enjoy Programming!!!

Wednesday, April 4, 2012

Agile software development and database refactoring

In the series of my blog posts in the context of agile software development, it’s necessary to mention “Database refactoring”.

Actually, the past few years have seen the rise of agile or evolutionary methods in software development. These methods embrace change in requirements even late in the project. The ability to change software is because of certain practices that are followed within teams, such as Test Driven Development, Pair Programming, and Continuous Integration. Continuous Integration provides a way for software teams to integrate their work more than once a day, and promotes confidence in the software that is being developed by the team. It is thought that this practice is difficult to apply when continuously integrating the database with application code; hence, Evolutionary Database Development is considered a mismatch with agile methods.

A database refactoring is a small change to your database schema which improves its design without changing its semantics (e.g. you don't add anything nor do you break anything).  The process of database refactoring is the evolutionary improvement of your database schema so as to improve your ability to support the new needs of your customers, support evolutionary software development, and to fix existing legacy database design problems.

Database refactoring does not change the way data is interpreted or used and does not fix bugs or add new functionality. Every single refactoring to a database leaves the system in a working state, thus not causing maintenance lags, provided the meaningful data exists in the production environment.

An example of database refactoring would be splitting an aggregate table into two different tables in the process of database normalization.

Key points in the favor of database refactoring:

  • A change to the table structure of your database schema.
  • A change which improves and/or ensures the consistency and usage of the values stored within the database.
  • A change which ensures that a referenced row exists within another table and/or that ensures that a row which is no longer needed is removed appropriately.
  • A change which improves the overall manner in which external programs interact with a database.
  • A change which improves the quality of a stored procedure, stored function, or trigger.
  • A change which changes the semantics of your database schema by adding new elements to it or by modifying existing elements.

Enjoy Programming!!!