you are here: Home Blog Product

Most organizations, especially the older more enterprise ones, are crippled with environment complexity - what started as Dev / QA / Prod quickly had a stage environment added, maybe a UAT, then perhaps a few QA environments for various versions.  Sitting on top of those numerous environments may be race conditions - who can test when - as well as challenges with getting data, content, dependencies, etc in the right environment.

The problem here is that this view on 'move my application through environments' is fundamentally flawed.  The environments were a response to an unknown.  We need to be able to test this outside of a dev workstation - create a qa environment.  We need to load test this - create a pre-prod environment...and so on.!StumbleUpon!

Standard background - I believe in open source, always have and always will.  With that in mind, the comments below are not a knock on open source, they are an expressed desire for better software experiences and better products.  I hope that some of the observations and learnings below will lead to better JBoss solutions as well as hope it helps teams in general reflect on their products and the message it is sending.

I had sent some of these comments around to my peers and former colleagues and there were requests to make this more visible.  With that said...!StumbleUpon!

Why are you estimating defects?

Regardless of popular sentiment, there is still a large number of organizations that are estimating their work. Lets put the validity of story-point estimating as a necessity aside – accept that, for now, there is some need that is felt to be filled by estimates. If you must estimate, please do not estimate your defects and include those in your velocity calculations.!StumbleUpon!

I consider myself lucky to have a varying group of individuals that I have met over the years with whom I can speak rather frankly about products - not just delivery but discovery.  I have seen an interesting pattern evolving - people want evangelists.  Gone are the days where it was enough to be a solid developer, great requirements writer, or an effective manager.  The times - they are a changing - and that is a really good thing.

I was speaking with a colleague a few weeks back who was working on somewhat of a startup and was using outsourced development.  He asked me a seemingly loaded question - 'How come the developers only care about me telling them exactly what I want, then they hide off and come back with something I don't need?' 'Well,' I responded, 'you are working with the wrong developers.'  By nature, the outsourced model is designed to remove any collaboration and focus strictly on savings based upon contractual obligations.  Perhaps a better name would be 'sunkcosting'.!StumbleUpon!

Constant focus on quality and code health is critical for the long term viability and maintainability of software.  This focus on quality is a trademark of agile teams but you don't have to be 'doing the Agile' to focus on quality. Regardless of how you develop software, testing and in particular unit testing are an important tool to have in your toolbox.  Given the importance of unit level testing, why do so many companies struggle with unit testing and its adoption? When unit level testing is non-existent or inconsistent, the reasons fall into two main categories:

  • General misunderstanding on what a unit test provides
  • Developers aren't good / shy away from testing as it is out of their comfort zone

There is a third reason, more like a myth, that is very popular - the myth that 'we don't have time to test'.  This is false - nothing will slow you down more than writing as much code as you can without some way of constantly being able to verify you haven't broken your assumptions of the intent of the code.  We tend to hear this myth coming mostly from developers.  This comment is usually rooted in a blend of the two primary reasons with the majority of the cause coming from developers simply shying away from testing.!StumbleUpon!

Some people much wiser than me have made comments such as 'The cost of version 3 of software is exponentially greater than version 2' and '

Think about that.  We may never see a 'version 3' of ebay or amazon. And maybe we don't need to.  The cost of such an endeavor, to replicate what those applications are providing, would not be trivial and the return on such an investment may very well never be realized. 

In enterprise software development, we see plenty of high version numbers.  Some of this is valid - we learn more about our customers and we create solutions to help solve their problems.  If we can say 'Here is how this functionality helps save me time / solve a problem' - then the software could be worth writing.  If instead it is 'It would be cool if the software did this' or the famous 'we need to re-architect the solution' - then we should take a hard look in the mirror.  How many applications out there have some AJAX functionality just for the glamor of it?

Software development is a sunk cost.  Understand that and accept it.  While I am not trying to put people out of work, understand that at some point your software is as complete as it needs to be.  Instead of allowing people to work collaboratively on solving the next problem, too often we create work to keep people employed (more to come on 'Resource Planning').  The changes requested for this software don't create any large tangible benefits, but it will keep the delivery team busy for a few months.  Its ok to not have delivery teams trying to deliver all the time.  Its actually probably cheaper.

Please don't focus on keeping people busy to keep them busy.  Instead focus on having your teams research and understand what your consumer wants and deliver upon that. Not only will you end up with a better offering and a competitive advantage, you will find that you now have a staff of highly engaged people solving problems and not just going through the motions.!StumbleUpon!