What Makes a Successful Software Project?

Man and woman using a laptop computer

Solve a Real Business Problem

Some software projects succeed, and others fail. What’s the difference? What are the clues that indicate whether a software project is going to succeed (or fail)? Here are some characteristics.

Number one, in order for any software project to succeed, it needs to solve a business problem. The magnitude of that problem, in terms of dollar value, needs to be greater than the money (time and effort) spent on the project. Otherwise, you’re just blowing an even bigger wad of cash.

Top Management Support

Number two, it needs the commitment and support of top management. Invariably there will be conflicts with allocation of people, time and money. Without this commitment and support, a loss of these resources can cause a project to be delayed, de-scoped, or both. The end result can be disappointing to the business customers. Having this commitment means having an executive on your side to advocate for your project.

The Right Team

Number three, you need the right team in place. Mainstream software development refers to “the three amigos”: product owner, developer, and tester. You may have two or more people fulfilling the developer and tester roles, it depends on the size of the project. Small projects can have the developer and tester as one person. But beware of carrying this into larger projects.

There is a marked difference in skill sets between a developer and a Quality Assurance (QA) tester. Developers are creators; they naturally want to build solutions to a problem. QA testers approach from the perspective of “let’s see if we can break this product”. Skilled QA testers come up with test scenarios a developer could not imagine. A good QA is worth their weight in gold on larger projects.

The Product Owner comes from the business side; typically they are a product unit lead. They can be a business analyst as long as the are knowledgeable, and have the authority to make decisions on behalf of the business customer.

The Right Technologies

Number four, you need the right mix of technologies. Server hardware or cloud provider? Software frameworks, and tooling all need to be matched with the skillset of the team. Additionally, consider the robustness and general industry acceptance of the technologies. Solid tools that are widely used means there is a large community of users to help you solve problems. Moreover, the availability of talent for your team tends to be higher with mainstream technologies.

Keep these tools and frameworks up to date; the last thing you want is to be struggling with five or ten year-old versions of software when newer versions elegantly solve the problem you are working on.

So to summarize, make sure you’re solving a business problem with decent return on investment, get management commitment, have the right team and use the right technologies.

But We’re Not Ready to Deploy Yet!

Pre-deploy work can drive you crazy.

Does it seem like you’re always waiting for something to be completed before you deploy your application to the User Acceptance Test (UAT) environment? You want to wait for the development team to fix the last few bugs. They have not yet agreed on which transaction manager to use. We’re only a couple days away from finishing feature X. We might have time to get feature Y in. There is no end to the myriad of details to sort out and questions to answer before you deploy.

Not only that, the product owner or project manager is getting impatient. You promised her it would be deployed two weeks ago, but due to factors beyond your control there’s still more work to do. The Quality Assurance (QA) folks have their test scripts ready to go, but they’re just twiddling their thumbs while they wait for you to deploy the application.

Read moreBut We’re Not Ready to Deploy Yet!

Are Microservices The Same Old SOA?

Are microservices the same old SOA (Service Oriented Architecture)? Isn’t it just a rehash of the SOA hype? Let’s discuss the similarities and differences.

While microservices and Service Oriented Architecture (SOA) are two architecture patterns that deal with services, they have some differences. In fact, despite all the attention you see being given to microservices there are a couple use cases where SOA is the better choice.

So What Is a Microservice?

A microservice a stand-alone process that communicates with its clients using a lightweight mechanism, usually HTTP. Its datastore is a database of some sort. The service is the only application that interacts with its datastore. So let’s say for example you have a CustomerService that reads from and writes to the CUSTOMER table and any related child tables. Only the CustomerService performs SQL actions on those tables; any other services that do something with Customer information must go through the CustomerService using its published interface.

Read moreAre Microservices The Same Old SOA?

The Grail is Eating Properties

Problem: You are developing a Grails application. You are using scaffolding to build out your views and controller actions. Yet for some mysterious reason Grails is not rendering some properties in the views.

Solution: Did you designate some properties as transient? If so, then by default Grails does not generate transient fields in views. To fix this you need to install the template plugin, and change the value of the persistentPropNames variable:

  1. Install the view templates:
    1. grails InstallTemplates
  2. Now open the pertinent templates (list.gsp, show.gsp) in src/templates/scaffolding
  3. Change the line that reads allowedNames = domainClass.persistentProperties*.name to allowedNames = domainClass.properties*.name for each template.
    1. Note you are changing persistentProperties.* to just plain properties.*. This opens the door for Grails to generate fields in your views that include your transient properties.

Thanks to lo_toad for pointing this one out. This solution saved me so much time.

Living In A Subversive World

This describes how to use Subversion on a day to day basis. If you have inherited or been assigned to a software development project that uses Subversion, but are unfamiliar with how it works and how to use it, then this post is for you.

So What is Subversion?

Apache Subversion is a Source Configuration Management (SCM) system that has one central repository, usually located on a web server. Each of us works on our own copy of the Subversion-controlled project. When post our changes back to the central repository, Subversion merges them with the existing code and increments the Revision number. Anyone who then updates their local copy of the project will now see the changes we just made. As long as everyone performs frequent updates to their local copy, it all works fine.

What’s So Great About It?

Subversion uses the copy-and-merge philosophy, in contrast with the Lock-Modify-Unlock method used by older SCMs such as RCS, and Microsoft Visual SourceSafe (VSS). In these systems, only one person can change a file at a time, while everyone else is locked out. Veterans of RCS or VSS may point to a risk of running into conflicts and other problems when using Subversion’s copy-and-merge. While the risk of conflicts is still present when two or more people are working on a file, in practice this is only a concern when these people are changing then same part of a file.

Read moreLiving In A Subversive World

Personal CI

If you could do something that would dramatically improve your job prospects in the event you leave your current employer, would you be interested? What if you could boost the value you deliver to your existing employer, and perhaps get assigned to that cool new project you heard about, would you be interested? Read on…

A popular acronym in the software development world is CI – Continuous Integration – in reference to the practice of performing automated build and test every time a change is made to the software. But CI also stands for Continuous Improvement, an attitude that one never stops learning. It’s a constant pursuit of better ways to do things, of new skills to learn. The Software Craftsmanship movement has as its foundation the notion of continuous improvement.

As we all know, information technology evolves at breakneck speed, effectively reinventing itself every three to five years. If we are to maintain pace with this revolutionary change, we need to keep learning, trying new technologies, and new languages. We need to have that sense of curiosity, of wonderment, of thinking “what if we did this…” and “what’s this “X” all about?”.

And if you don’t? Well, some may be able to stay with their current employer and effectively cruise to retirement. I’ve seen this work for some people. But then what happens if you are laid off, or otherwise need to leave your present employer? Your skills have probably stagnated, and become out of date. Your only hope is to get hired by a company having a similar technology stack and development methodology. But if your skills are in low demand out there in the marketplace, you’re in a world of hurt.

Take charge of your career development. Make yourself the one who gets you the skills and training you need. This is going to mean paying some costs out of your own pocket; however, you may be able to get some tax breaks here – speak with your tax accountant. Attend conferences, either local or out of town. Join your local Java Users Group or Meetup Group. All of this is an investment in yourself that pays off in many ways, not just monetary.

Mentor others in your newly-learned skills. Talk to your boss and offer to run a lunch-and-learn session. Look for opportunities to pair with a colleague to help solve a stubborn problem. The personal satisfaction you get from sharing your knowledge with others is pretty cool.

Design is Important, But…

Spending time on software design is important because it helps you solve the big problems up front. Without this effort, developers can get bogged down, or worse, build something that doesn’t meet an important customer requirement. What you want to avoid is spending too much time in the design phase. After all, our objective is to deliver working software to our customer early and often. At some point we need to “get on with it”. The trick is to recognize that point

When do you know when to take a break from design and start building something? Well, one clue is when you find yourselves bouncing back and forth from one design option to another. Ask yourself, might this vacillating be due to a lack of information? If you’re speculating on what may be important to the customer, talk to them. Clarify what their needs are. Ask them what would exceed their expectations, and what would disappoint them.

If you have design options that would equally satisfy your customer, are you lacking some technical information? Specifically, how well do the capabilities of the technology stack support each of your design options? If this is the case, then it’s time to see what will work. Decide what metrics are important enough to help you decide on a design, then go and make a prototype. Take one of your design options, and build it out enough for you to benchmark it. Show it to your customer and get their feedback. Then take your other option, benchmark it, and get customer feedback. Repeat this for a
third option if you have it. Now you have some empirical data to help you with your decision.