The Software Quality Poem

By mOrPhie on Tuesday 14 September 2010 22:49 - Comments (10)
Categories: business, software engineering, techrelated, Views: 5.306

Bugs, faults, errors and defects
They are all the same to me
Please ignore the name
Value the severity

Feature popularity
Specification compliancy
And customer satisfactory
All define the priority

Unit testing, code review
Architecture and design
Prevent a list of bugs to grow
And make the software shine

So, if you find yourself
Fixing a bug or three
Think of this poem before moving on
And improve software quality


Quality vs. Functionality

By mOrPhie on Saturday 12 September 2009 17:21 - Comments (8)
Categories: business, software engineering, Views: 3.211

Building software on a budget is never an ideal situation. You are forced to make a trade-off between quality and functionality. You cannot have both or you will go over budget.

Most of the time, quality is forgotten and the budget is used for more functionality. The problem with this approach is that more functionality does not always helps you get the job done better. Roughly 80% of the time, you are using 20% of the functionality. Another problem is that forgetting quality almost always leads to going over budget, because buggy software needs to be fixed.

You should find and build that 20% core functionality first and make sure it meets your quality criteria. It will keep you within budget and won’t clutter future release schedules with bug fixing old releases.

Don't forget the process

By mOrPhie on Friday 11 September 2009 00:29 - Comments (4)
Categories: business, software engineering, Views: 2.656

A lot of line-of-business software automates a previously physical process. For example: project planning used to be a process on the white board and paper schedules, but nowadays this is done with software. Planning a project can therefor be done faster, cheaper and better.

An anti-pattern of line-of-business software development is developing unneeded software. It seems like a great idea and software is used to spawn the new business opportunity. The process and business case are forgotten. The risk here is that the software won't match your expectations because there is no cohesion between the software and the underlying process.

So, if you want to be safe: set up a business case, define the goals, define the process and be sure it works. Use software to support the process instead of being the process and dodge a lot of frustrations.