Agile

The Application Delivery Deadline — Good or Evil?

“Do You Really Need a Deadline?” is a post I found interesting in the light of my current “deadline” pressures.  Related to the post, I also found comments on the post to be interesting, such as this one which said “I NEED deadlines to work. If I don’t have them, I don’t get anything done. The worst thing possible for me is to be given time.”

In the referenced post I absolutely loved the statement that “With custom on-demand projects, clients often fail to understand that meeting a deadline and completing a project on time is the responsibility of both customer and vendor …”  While I’ve never really thought of it in quite the same way, I’d have to say that the statement reflects my experience completely.  I’ve often commented to associates that when I first meet with a prospective client I’m interviewing them as much as they’re interviewing me.  There are prospective clients with whom I’ve met that I hoped would never call me back. In many cases I had perceived in our preliminary discussions either that they wanted something for nothing, wanted yesterday with no responsibility of their own, or were so set in the “way it has to be” that we just didn’t “fit”.

As for deadlines, they can sometimes be set as the result of outside factors over which one has no control such as buying a new company and having to replace their system which was under the control of another larger, remote entity — after a certain date it would no longer be available.  The deadline is very real, as opposed to arbitrarily assigned deadlines based upon nothing more than “who knows what logic?”, maybe just a “nice-to-have” idea.

IMO deadlines are NOT evil — unless — they are totally arbitrary and unrealistic, or so structured for adherence that a vendor will sacrifice quality or reliability “to meet the deadline”, or invoke any one of a multitude of other negative events to “appear” to have met the requirement.  Let’s face it, that many need a deadline to get anything done is not uncommon, but may that deadline not be life or death.

Custom Application RFP Process Approaches

My posts last month generally consisted of comments, suggestions and difficulties with preparing cost estimating of legacy applications.  Recently I had the opportunity to come accross an interesting blog post which relates to “the other side” of the coin, that of preparing the RFP.  While the post doesn’t directly relate to an RFP to replace an existing legacy application, certainly there are points of comparison.

Agile Development Improves ROI - But RFP Processes are Stuck in Waterfall is the posting to which I am referring.  Early in the article it is stated that “The typical RFP process for custom software development is looking for a fixed bid, thinking this will provide budget protection and guarantee ROI.”  There are many pitfalls to this way of thinking, not the least of which is that it doesn’t really hold up in fact, in a large part due to inadequate requirements.

Then there is the “feature set” to be considered, an area which I commonly dig into with my clients — always using the “…delivery of valuable software” idea of the Agile Manifesto.  As for features, the post makes the statement that “…studies show that 45% of features built under waterfall are never used.”  WOW!  The common cry of “If its not broken, why fix it!” should be replaced with “If it isn’t used, then why have it?”  Many is the time that I have been with a client and seen that there are always areas which just don’t get used.  Unused fields in a database always seem to be asking the question - what am I doing here?  Sometimes it is a change in process that has made it obsolete, but more often than not I find it is a matter of some program area which “seemed like a good idea at the time”, but which just never fit what was envisioned, therefore didn’t provide the “value”.

As for preparing an RFP — I wonder about the effectiveness of most RFP’s, and the referenced article helps me identify why, it seems to demand a waterfall approach, and I’m clearly into an Agile approach to development.

Small Business Application Development and Use Cases

While there is no shortage of writing available on the internet or in software development textbooks regarding the various software development methodologies available, I find that the great majority of it is really geared toward managing large projects for large companies.  Since I develop for small and medium size businesses who often have very limited budgets for development, I am always interested in the processes and methodologies that can help me produce better software for my clients.  My clients IT infrastructures often leave something to be desired - and therefore often I become an infrastructure consultant as well as software developer.

My reading this week pointed me to an article on the SearchSoftwareQuality site entitled “Useful app dev practices trump full-blown processes.”  The article, written about prominent software methodologist Ivar Jacobson touches on how Jacobson is willing to rethink processes and practices, something which is always difficult to do either because of time constraints or because of being reluctant to admit that something which you previously had thought was so great - perhaps isn’t, or needs to be modified.

Custom application software needs to be reviewed regularly in order to maintain or increase its value as it is used.  This is no trivial task.  I’m currently in the process of conducting 2 such reviews for clients, and they are taking considerable time — and it is these reviews which bring me to “Use Cases” and another article titled “Five use case traps to avoid“.  Use cases can be a very valuable methodology to incorporate when reviewing existing software, procedures and planning future rewrites or modifications to the application - even for small projects, creating such a document will help solidify understanding and communication among the analyst, developer/programmer and client.

Robotic Arm Programming, Mars and Agile Methods?

I read with great interest an article about the recently successful Mars Lander “NASA: Robotic arm key to finding life on Mars”  In particular what caught my attention was that the programmers for the mission are sending daily code updates to Mars to guide the robotic arm as it gathers and prepares sample for analysis.  They are on a daily schedule of writing, testing and sending new code sequences to their “baby” on Mars!  Sounds like a story straight out of science fiction!  (I wonder if this is considered an Agile team

The article refers to the sequences taking about 20 minutes, and then 12-16 hours later feedback from the Lander.  Certainly there’s no pressure to get the code right the first time - is there?  Well, there is also the pride of the development team — my hats off to salute them!  What an accomplishment!  Man and machine, working together - what a team!

May our programming future enable such flexibility, whether we program for business, medical or space exploration.

Thoughts on Agile Methods

I ran into an article published back in January 2007 entitled “We are all Agilists now“, written by Matt Stephens.   As an independent developer since reading about Agile methods I’ve always been interested in the whole concept of Agile particularly as it would apply to the small developer group - especially the group that is geographically challenged. 

Stephens’ choice of title caught my eye and I liked what I saw.  The concept of agility as more a state of mind than a set of concrete practices I found particularly interesting.  I found the article thought provoking and worth the read - perhaps you will as well. 

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 »