The right kind of project management methodology can do wonders in software development. However, when it comes to choosing one, people would want a lot of questions answered.

What is this Agile methodology we’ve been hearing about?

I’ve heard it’s quite similar to Lean methodology. Is it?

Does Agile actually mean Scrum?

Agile and Lean have been around for a very long time. But choosing one of two has always been under debate. There is a relationship between the two which is often misunderstood.

This is just a simple analysis of what each means, and how they are connected. But first, their history…
 

Lean

 
Originally derived from ‘Lean Manufacturing’.

Lean Manufacturing, according to Wikipedia, is a method devised for the elimination of waste within a manufacturing system.

The Lean methodology, from a software project management perspective, is basically a set of principles that will help achieve speed, quality and customer satisfaction.

You may have heard something similar about Agile development methodology as well. Therein lies the source of confusion.
 

Agile

 
Back in the days, there were some hardcore methodologies in software development. They were popular all right, but kind of defeated their own purpose. How?

You see, these methodologies started stultifying software projects, preventing them from providing the result they were meant to. Software projects were meant to create software that helped the customer. With those methodologies, things went sideways. At that time, the Agile Manifesto was formulated as a reaction….or better yet – a solution.

So Agile basically refers to the principles proposed in the Manifesto.
 

The confusion

 
A woman named Mary Poppendieck who had worked in a manufacturing plant, worked with her husband Tom Poppendieck, a software developer, to figure out a way to adopt some manufacturing principles in the software realm. That intellectual concoction, ladies and gentlemen, is what we call Lean.

Interestingly, Mary was also the founding board member of the Agile Alliance, that introduced the Agile concept. Strong lean-influenced ideas obviously had a key role in the origin of the Agile Manifesto.
 

Lean and Agile

 
History lesson is over. Time to focus on the topic at hand.

So the ideas from Lean manufacturing has been applied to software development. This kind of defines the way Agile works. Hence the similarity. Both Lean and Agile is based on a combination of customer-centric approach and adaptive planning. As a matter of fact, Lean manufacturing did influence Agile enthusiasts or Agilists as they are commonly called.

Lean is about eliminating waste right? So in the software realm, the idea is to eliminate anything that doesn’t have value, and work on only that which is absolutely necessary. That ‘anything’ could include documentations, meetings, certain tasks etc. Inefficient ways of working will also be eliminated, thereby delivering results faster.

Here’s what one can derive from Mary Poppendieck’s words.

Lean = Rapid Response + Quality + Discipline + Speed-to-market

Agile, on its own, focusses on short iterations. A functional software will be delivered in the end after thorough testing, scrums, sprints and a lot of other facets.

The Poppendiecks’ approach was to blend Lean with Agile. This Lean-Agile combo will include the iterations of Agile development, and the validation practices of Lean. They are deeply entwined when applied to a software development environment. One isn’t exactly an alternative to the other. So, in a nutshell, if you are using Agile, you are using Lean as well…and vice versa.

The point of interest is where you decide to use the ideas from Lean manufacturing in your Agile methodology. So there isn’t actually a victor in this face-off.

To conclude, there isn’t a big difference between two except at the core. Lean software development focusses on elimination of waste so as to improve the processes, while Agile software development methodologies adhere to the principles in the Agile Manifesto (eg: Scrum).

With that said, a good Agile development team will adopt the best technical and management practices (which will include the principles of Lean as well) that work best for them, and leave their customers satisfied in the end.

Technology plays a critical role in web stacks. Web stacks have always evolved in parallel with technology, over the years. We will be discussing LAMP stack and MEAN stack today.

LAMP stands for Linux, Apache, MySQL, and PHP/Python/Perl.

MEAN is an acronym for MongoDB, Express.js, Angular.js, and Node.js

There still seems to be a confusion when faced with a choice of MEAN or LAMP stacks for web development. The backend languages, server environment and databases are different for both.

Let’s discuss the pros and cons of MEAN and LAMP stacks with respect to 3 key areas – Web server, database and operating system.
 

The Web Server

 
Apache provides the web server for LAMP stack while Node.js holds that responsibility in the MEAN stack. LAMP stack has been there for a long time. And that is also one of the reasons why Apache is considered a mature technology, where you can get new extensions when they are available.

As for Node.js, it’s a relatively new technology. While you still get quite a few active plug-ins, you will still have to write your own plug-ins to cover those areas missing necessary functionalities. Node.js is event-based and also locks codes on the web server into JavaScript. This can complicate things when you try to convert a sophisticated back-end program.
 

Database

 
LAMP uses MySQL or other relational databases while MEAN works with MongoDB, a non-relational database. If you are in a situation where you have to translate the data in an existing SQL database, you will soon find it tiresome to remove redundant object attributes, and may have to rely on a custom software for this purpose.

Relational databases are comparatively easier to work with but is on the verge of becoming outdated. MongoDB features faster data retrieval and is more scalable though.
 

The Operating System

 
LAMP stack locks the operating system to Linux and its variants. There are no such restrictions in MEAN, as you can run it in any OS compatible with Node.js. Linux isn’t your only option if you are using MEAN stack, though it is still considered to be the best OS for a server environment.

Both LAMP and MEAN have pros and cons in all 3 key areas. Let’s assess a few more facts before concluding.
It is said that you can only master MEAN stack once you have mastered JavaScript. It’s going to be a tad tedious, but worth it. However, LAMP stack works with front-end JavaScript and back-end PHP, just comfortable enough for developers to develop an application without much worries.

While MEAN stack is faster and more scalable, LAMP is a tried-and-tested web stack with a secure infrastructure and a large support community.
 

Conclusion

 
Although many developers claim that MEAN stack will eventually replace LAMP stack, there are others who still believe in the latter’s potential. LAMP is time-tested, stable and sturdy, with tons of online tutorials and support availability. Its back-end architecture allows you to do whatever you want to do on the front-end. MySQL is still one of the most widely used databases.

MEAN stack features a single language from top to bottom, in addition to flexible deployment and faster data retrieval capabilities. You are free from micromanaging schemas and migrations in the database as it uses a non-relational NoSQL database. With JavaScript gaining popularity, MEAN stack is attracting more developers every year.

Deciding between LAMP and MEAN will mostly depend on the organizations you work for and the projects under development.

For fourteen long years, ASP.NET has been giving developers a good time. The framework experienced a lot of changes over these years, leading to its most recent successor – ASP.NET Core 1.0.

Originally announced as ASP.NET vNext, it was later referred to as ASP.NET 5. But because the core concept was new and due to a couple of other reasons, ASP.NET 5 was renamed ASP.NET Core 1.0. One reason for renaming was that the Core 1.0 framework wasn’t designed as a replacement or a continuation of ASP.NET 4.6.

It’s an all new modular and comparatively smaller framework that works well with everything else we know about ASP.NET Development.

What does it bring to the table?

 
ASP.NET Core 1.0 is a full re-write. It’s an open source, cross-platform framework with an alternative to Mono – CoreCLR, allowing developers to build and run applications on both CoreCLR and Mono regardless of the computer’s operating system. Node.js has been heavily integrated into the framework to run pre and post build events.

Microsoft took a big leap by introducing a new IDE in the form of the Visual Studio Code editor – open source as well. Apparently, Microsoft went to great lengths and invested heavily on ASP.NET Core 1.0 to make it cross platform portable.

But why?

 
Running applications in not just Windows but Mac and Linux too? Yes, it seems. But why would Microsoft invest so much to attract developers who don’t use Windows? They are already keen on using effective technologies they are familiar with and it’s unlikely they will use MS SQL server in their projects.

Visual Studio Code is free as well. Though it doesn’t matter, there is no clear answer to these questions apart from a few speculations. The .NET community is shrinking. It could be the reason why Microsoft decided to go completely cross-platform to attract .NET developers from every nook and corner.

Without .NET developers, demand for Microsoft Azure and MS SQL will dwindle. Think about it. Windows desktop application development is taking its last breath. The mobile app market still belongs to Android and iOS. This leaves web applications development where ASP.NET still reigns (sort of) despite heavy competition.

Now non-windows users will also be able to develop web applications with ASP.NET Core 1.0. The lack of portability issue has been addressed as well. Things are finally starting to look good for Microsoft.

The Replacement

 
The ASP.NET 4.6 was a disappointment for many developers as they didn’t get to try out big innovations. The innovations were not readily made available in the Windows platform. The developers couldn’t keep up with the vastly changing technology and knew little to nothing about new innovations that other open source frameworks provided.

Add to that the lack of cross platform compatibility, and it will make more sense why ASP.NET community became smaller.

This is why ASP.NET Core 1.0 is considered to be a game changer.

• Open source
• Cross platform compatible
• Fast, modular and extensible
• Can be developed with languages like C#, F# etc.

ASP.NET 4.6 is living on borrowed time and will eventually go down in history as the new classic ASP.NET. But for now, it won’t completely vanish. ASP.NET Core 1.0 offers some exciting prospects with compelling features. The future of web development looks bright at this point.

There has been a lot of discussion going on in the internet on Service Oriented Architecture (SOA) and Microservices lately. There were a lot of debates as to what makes them different from one another, and which one is better among the two. There were many valid arguments from both sides.

While some consider Microservices as the future of architectural style, many others still prefer SOA. Let’s get an idea on our contenders so we can come to a conclusion.

Microservices

 
Considered to be the modern day go-to architectural style for developing highly scalable applications, microservices addresses quite a lot of problems associated with large, cumbersome applications. It’s a service-based architecture with independently deployable services as the primary components.

It provides better control throughout the development, testing and implementation cycles, but has a limited service taxonomy when you consider service type classifications. It also makes use of an inter-service communication protocol (REST, JSON etc.).

SOA

 
SOA can defined in many different ways because this architectural style has been constantly evolving over the years. It was designed to bring order to sophisticated combinations of enterprise-level software by representing them as collections of services. SOA also uses service communication protocols. It can be considered as a superset of microservices.

It relies on a shared data model. The model will have complex relationships between numerous data structures and models, and multiple hierarchies. The tiered organizational structure of SOA facilitates service coordination and messaging functionalities.

Now that you have a basic idea, let’s get ready to rumble. For starters, let’s make this a three rounds bout.

Round 1: Services Decoupling – SOA is based on a shared data model. Therefore, you can expect it to have tight data coupling between services and other system components. This makes it quite resistant to changes. Some additional re-testing might be necessary in some instances to make sure that changes haven’t negatively affected any service.

Microservices architecture runs with a concept referred to as bounded context, which promotes an association between a single service and its data. It isn’t possible to completely eliminate sharing of services but it can be considerably minimized. Whenever sharing is required, it’s avoided by replicating common functions across services instead of using data sharing. Though this data decoupling facilitates deployments more often, it also cuts down testing scope.

Round 2: Messaging Middleware of SOA vs Microservices’ API Layer – SOA’s multi-tier model features a central messaging middleware layer. As for microservices, there is a non-coordinating API layer over the services that constitute an application.

Messaging Layer key points:

• Additional capabilities including message transformation, mediation, and routing.
• Elevated data and functional coupling degree
• Increased complexity
• Increased deployment and maintenance costs

API Layer key points:

• Simpler than messaging layer of SOA
• Easy to change granularity of services
• Easy to change internal data representations
• No modification required of the requesting application (for both changes)

Round 3: Coordination of Services – With a central hub controller, SOA maintains order in the execution of services. Microservices use inter-service communication protocols for the same.

A microservice can call another microservice whenever necessary so as to complete its function. The service that’s been called can call other services as well (a process called service chaining). Too much chaining isn’t advised and should be avoided as it indicates a degree of functional coupling with no benefits at all.

Conclusion and Verdict

 
Both subjects in question appeared good in the 3 rounds. However, one cannot replace the other as there are many other variables that indicate further distinctions between microservices and SOA.

While SOA can address a set of heterogeneous applications in sophisticated enterprise systems facilitating shared services across applications and functions, microservices is an optimal approach for web-based, smaller, less-complex applications. These applications do not require explicit service coordination.

Because of granularity and high independency of services, the microservices’ model finds a place with continuous deployment models of software development.

The verdict from the above arguments would slightly tilt in favor of microservices. But both of them can be highly effective depending on the context where they are used. Microservices approach can deliver agile applications that can necessarily transform into an SOA-styled architecture.

SOA, on the other hand, can apply microservices principles for better statistics in maintenance and performance.

Conclusion? Both are effective depending on the working environments. It’s a tie.

You may already know a few variables that you need to consider so as to find the right partner from a large number of software development companies in the market, to help grow your business. But do you ask the right questions? There are a lot of factors to be taken into account before hiring a software provider.

With your business growing, you will eventually have to acquire a software that caters to your business needs. This is basically a race to get your business into the digital realm and expand it.

GET, SET…

If you think the first step is to shortlist good companies after a couple of hours in Google, you are off to a shaky start. The first step is to clearly define what your organization needs, taking all aspects related to it into consideration.

• Do you expect a sales boost with the software?
• Do you expect increased operational efficiency or just bring order to the chaos with a software?

There are many things that you can list down.

The second step is “Market Research”. This step is supposed to be time-consuming.

• Find out about the market
• Compare it with your business needs
• Identify the software requirements that work well in the market environment

Now see if a software catering to your requirements already exist. A pre-existing software is a better option than building one from scratch, but make sure it isn’t outdated. If it doesn’t, let’s find a good software company for you.

GO…

Once you set out to find a perfect software provider, you can start spending some time on Google searching for good candidates. Once the list is ready, you need to understand each firm you have listed individually. Factors involved are many, and reputation of the firm alone will not cut it. So let’s explore the things you need to know.

Technical Expertise: The most critical factor of software development is Technology. You need to be aware of the technology best suited for your software and the expertise of the software company in this technology. A good company can advise you on what technology works best for your business environment and hardware infrastructure. However, you need to ensure that they can properly leverage this technology to build an apt software.

Company Portfolio: To get a grasp of what the custom software development company is capable of, you can ask for their portfolio, which should include information on:

• Their past projects/success stories
• The technologies they used and how it benefitted their clients
• Client testimonials
• Company lifespan and industry experience
• Their pricing structures

Do a deep research to get an idea of their competency. A good company will have developed unique development methodologies to ensure the completion of a project on time. You need to make sure they don’t compromise quality for on-time completion. If they have offshore development centers, you can get products at generally lower production, delivery and testing costs.

Status Update & Delivery: You should make sure that the software company in question can give you regular status updates regarding development until delivery. There are many firms that offer transparent development methodologies where you will be able to see the progress and call for modifications whenever and wherever necessary. Make sure they complete each phase of development on time.

You don’t need to tolerate excuses for not delivering on time, as on-time delivery is very important. Even after getting the product, you may need more time to get your own employees trained to use the application. It should be specifically stated during the negotiations and in the contract. Certain companies can give a working prototype so you can start training your employees while the software firm finishes up with a fully functional product.

Pre and Post-development Support: Pre-development support is important but rare to find. Competent firms can give you complimentary or paid advisory services where experts will let you know the pros and cons of using a particular technology for software development, how the software will operate in changing business environments etc.

Know that delivery or installation of the final product isn’t where the deal ends between you and the software company. Companies usually give you a walk-through of the software and its features before closing the deal. But it’s better to make sure they also offer post-development support services like helping you with application configuration, maintenance and backup, and future upgrades etc.

FINISH…

Mind you that these are not the only variables to take into account. There are many others including flexibility, project management etc. However, the ones mentioned are the most critical while choosing a right software provider.

The race ends here but it’s up to you to discuss every aforementioned aspects with a prospective software provider, get clarifications and negotiate the cost of their service before including them all duly in the papers and getting them signed.