Unified ALM Hybrid with a single DevOps approach at Common Annual 2017

In many conversations with IT project managers and Application architects our team sees one recurring pattern, the need to work with a unified DevOps approach. The approach should be a simplified and seamless experience for all the involved teams at all stages of the development process. Think about it, this is a huge difference how DevOps should be doing and what is really happening in day-to-day operations. A lot of companies promote ALM solutions which are always shiny and look nice on paper.

Remain Software at IBM i user groups' conferences

It's a pleasure for Remain Software to meet IBM i enthusiasts on user group conferences. It's a fantastic opportunity to get to know and learn from each other. It's great to see how strong the IBM i community is and how many people are looking for professional development, networking and learning new skills related to the IBM i development. So far this year, we have attended several conferences and many more are coming. The next one in July (EPiC OCEAN 2016 IBM i Technical Conference in Costa Mesa, California) and several events in fall.
workflow management, task management, project management

7 tips on how to be more productive at work

According to McKinsey*: The average interaction worker spends an estimated 28% of the workweek managing e-mail and nearly 20% looking for internal information or tracking down colleagues who can help with specific tasks. Is this how it should work? Shouldn't employees actually focus on the core tasks, instead of the administration part? Read the following tips and learn what can you do to increase the effectiveness of your work and get more things done in shorter time!

Obvious statements about software change management: #4 How to make audit costs less painful?

Auditors' work implies a lot of responsibility so they need to be careful and thorough. Auditors, especially SOX auditors, can charge your company anywhere from $150 to $500 per hour; they are expensive in Euros too. So, the goal is to make the auditor happy with all information he needs and get him/her out of your office as quickly as possible.

Obvious statements about software change management: #5 Everything is related. A small change can have big effects

There is a theory which is called the butterfly effect. It states that the flapping of a butterfly’s wings in Beijing can cause a hurricane in the US. This is also called the chaos theory and it describes the relation of cause and effect in complex systems like the weather.

Obvious Statements About Software Change Management: #6 Multiple Versions of the Same Application Resurrect Bugs

Creating another version of your application can result in the replication of the bugs that exist in your original version. We call this the "Zombie Bug Pattern".

Obvious Statements About Software Change Management: #7 Multiplatform Development Requires Deployment Synchronization

Many of you develop for multiple platforms. This often means that some code runs on a database on your IBM i and other code runs on another platform such as a Linux application server or a Windows desktop.

Obvious Statements About Software Change Management: #8 Bugs are the most inexpensive when terminated early

Our opportunity to save some serious money is at the point of time when we really start believing that this is true. Of course, we know that it’s true, but in the end there is never time to do it right but always time to do it over. There is a reason why most companies don’t feel this pain as much as they should. At Remain Software we like to call this the “post-bug cost calculation”. There is not even a well-known expression for it because we never calculate how much a bug has actually cost us (did you ever do it?)

Obvious Statements About Software Change Management: #9 The Result of an Automated ALM Process is Documentation

What we do in an automated process in each of the change states is typically managed by electronic documents. For example, if a user reports a bug this is logged as a problem. Based on this problem the process will issue a change request. If we are advanced we will flag this in the problem document and we will log the details such as the date and time when the change request was raised.