Practical Software Development

In a prior post, I described being agile without Agile. I want to expand upon that post with a more general outlook on software development.

Bottom Line Up Front: Sometimes it is our methodology which is keeping us from being agile (even if we use Agile. :-) )

The first (and the hardest) thing we, as members of the product delivery team, must realize is that the act of the creation of the product is not the point. The point is to get customers paying for the privilege to use the product.

Paraphrased conversation with a Development Lead: Yes, I know you work for a software development company. Yes, I know that your methodology is great and you have read all the books about it and how it will make our product great. Yes, I understand that because of the way the team works you will deliver solid functioning software someday. However, if you don’t get the product/feature/tweak delivered very soon, there may be no software development company for you to work for any longer.

Believing the creation of the product is the point makes us navel-gazing, myopic and beholden to our processes and methodologies.

Meanwhile, the customers are waiting, the customer’s business is in pain because of something we need to deliver, the competition is leapfrogging us and our company’s business team is pulling out their hair wondering what we are doing!

We can shout, “They should just sell what we have!”, alI day long and there are times when that sentiment is appropriate, but in many cases what “they” are waiting for is the feature that is going to tip the sales scale in our company’s direction.

OK, if we can’t be bound to our processes and methodology, should we just “wing it?” Of course not. We just need to understand there are going to be times when our carefully laid plans will need to be set aside.

Here are some general guidelines of how we can determine when it may be appropriate to shortcut the methodology:

It’s Broken

We all know this one… It works exactly like the customer requested, but it is not what they needed. This can be made worse... there is hard cutover date we have to make. This just recently happened to me. There are no niceties like design meetings for this one. All we can do is get “all hands on deck” and power through it.

Cash is King

All companies run on cash. Revenue is great, but if it does not turn into cash quickly enough we are going to have a problem.

If we have a current customer willing to pay big bucks to get something “right now”, we really should just get it done and collect the cash.

Another possible source of fresh cash is a new customer who is willing sign if we show them a feature. We have to be very careful with this one. We must try to make sure someone other than the salesperson is in the meeting with the “buying authority” from the customer. Some salespeople have used this as the reason they did not close some business.

Quiet Space

I believe in creating “quiet space” in which to work. If the customers (or support or product management or sales or...) are up in arms about something all the time, it is very difficult to move forward on longer term projects and other items.

The first area to examine for creating quiet space is persistent errors. Sometimes, it is just easy to just fix the symptom or create a workaround. Not good enough. We must find the root cause so it never comes back. Line up a set of persistent issues. Get rid of them all. This makes the customers happy and the support team may buy us lunch. Most importantly, we will be left alone.

Another area for quiet space is creating tweaks for a customer or customers which allow us to buy “quiet space.” This amounts to, “If we do this for you, you have to promise to leave us alone for N weeks.” This really works well internally and with very involved customers.

Depending on the size of the team and the code versioning system we may be able to cover several of these at the same time. Our challenge is determining the best way to deliver these out of band releases without accumulating large quantities of technical debt and being able to fold them back into our standard delivery methodology. Modern tools and delivery platforms certainly help with this, but in my career I have made this work even without the modern conveniences.

We can develop great software and be practical about it at the same time.