Agile

Defining “Just Enough” Application Requirements

A little over a week ago an excellent tip was published regarding software requirements - “Approaches to defining requirements within Agile teams“.  While this tip directs itself to the needs of an Agile team, it serves as an excellent read for the software developer who is dealing with custom applications, and I believe applies as much to the custom development arena as Agile. Continued »

Software Quality and Ethics

Not many articles come along about which I feel I could become a cheerleader.  However, yesterday’s news on SearchSoftwareQuality.com featured an article entitled Test Driven Development and the Ethics of Quality – that is just such an article for me!  [Imagine a smiling, clapping Happy Face Here!].  I have been a believer in producing quality software since my early days of software development in the 80’s.  I must say that I never thought of software quality as an ethical concern.

Within this article, associate editor Jennette Mullaney uses a number of quotes from Robert Martin, who is the founder, CEO and President of Object Mentor Inc.  I really can’t say enough about this article — as it would appear that Mr. Martin and I are completely in agreement.  He thinks the way I do — which some might say is bit of a scary thought — for Mr. Martin that is!

I have been saying for quite some time that this is a fantastic time to be doing software development.  We as developers have multiple tools and capabilities available to us which greatly enhance our capability to produce quality software.  I believe that our customers have every right to expect nothing short of quality software from us as their developers.  This article makes reference to such topics as unit testing, agile development and test driven development(TDD).  If you are a developer and want a boost to help you commit to quality — read this article.  I highly recommend it!

Agile development methods and application value

An article entitled “BT adopts agile programming” came to my attention today, and had me thinking about how the development method used for a project can have a significant effect on application value.  BT as perhaps you know is the British telecommunications group, and they have seen significant productivity as a result of using agile development methods.  They began using agile development methods back in 2005.

The article I have referenced indicates that using Agile development methods they realized software development cycles which were a minimum of four times faster.  Given the size of BT, it takes no stretch of the imagination to understand how agile development methods have had such a significant impact on the application value.

Since a part of application value is established by the cost of developing the application, certainly the cost savings as realized by BT have a significant part in establishing application value.

I highly recommend this article as a good read.  In addition, there is another article that also makes reference to how BT utilized agile programming.  “Agile Delivery at British Telecom” is also an excellent read.

Developer - User Communications - Another Visit

Once again I find myself writing about the value of having good communication between the application developer and the users expected to use the program for their day-to-day operations.  Two noteworthy instances of this value came to me once again - just yesterday.  Each incident was unique in its own way, but the common thread was clearly communication - either poor, incomplete, misunderstood or a combination of all.  In each case the end result has been delay in getting the task completed. Continued »

The Challenges of Application Software Implementations

Contrary to what my blog may be showing, I have not been on vacation this past week, nor have I been sick, nor have I been tending to many matters other than the current projects I have on my plate.  I could certainly use a vacation after this week!

 It’s said that timing is everything.  Well it would seem that my timing is off because I currently have two clients in the throws of new software implementations, and neither one has been without challenges.  For one thing, the challenges at each have been as different as their respective organizations. 

The main ingredient and common thread among these two implementations has been more along the line of user challenges than the technical issues of the software design or network implementation.  You know how users are - don’t you? Continued »

Expectations in Software Development

I’ve heard it said before that an expectation unfullfilled leads to upset, and I must honestly say that I buy into that 100%.  How many times have we begun using a new piece of software with an expectation (or 2 or 3) that was left unfulfilled once we started using the software?  I believe that I can say for certain that it has happened to each of us on at least one occasion - leaving us upset because the expectation (probably unrecognized and undefined beforehand) was not met. 

With this in mind, I would like to explore some thoughts regarding just what some unspoken expectations for software are. Continued »

Learning a new Business

I believe that one of the most challenging parts of being an application software developer is that of learning a new business.  I further believe that it is essential at every level for members of the project team to have at least a minimal knowledge of the “big picture” of a project, as I’ve seen too many examples of applications failing to meet the user needs because of a lack of understanding.  In the small business environment in which I generally work I have found that the more I learn of a customers business the better I can provide what they really need  (…and want that they don’t even know how to express!).  I’m going through just such a learning experience now. Continued »

Being “Agile” without Face-To-Face Conversation

The sixth principle of the Agile Manifesto states:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  I find myself in complete agreement with this statement. 

However, this statement begs for an answer to the question “How can a team which is unable to be face-to-face achieve efficient and effective communication among themselves?”  Once again, there is no easy answer, and to achieve the desired result in spite of the inability to meet face-to-face requires a major committment to the project and the team.  Continued »

It’s Not Easy to be Agile

Paragraph 3 of the “Agile Manifesto” states this principle:

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”

Living up to this principle is no trivial task, not even for a team of developers!  I wonder how many really do, and what kind of project are they working on?  Doesn’t it seem like there are always new issues to deal with?  What about getting time to keep up with the latest and greatest available tools of our trade?  When does this happen? Continued »

No Lack of Development “Ideologies”

I find myself continuously amazed by the number of software development methods that are available, and question whether any single one could possibly “fit” any project.  (Please see my previous post “One-Size-Fits-???”)  My experience has been mostly with small to mid-size companies where application software is looked upon to perform many roles, just as are the users of the software.  This is a good thing — handle a transaction once and be done with it.  Continued »