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 »
Last Thursday I found myself off on a journey to the unfamiliar for me by attending the Microsoft “You’re In Control” Launch in Boston. My decision to attend was based upon the fact that I can honestly say that I’ve never gone to an event where there would be other IT people and not gained “something” out of it … and I expected this event to be no different than previous experiences. I was not disappointed. However, what I did get out of the time invested (…it is an investment isn’t it??) looked nothing like what I thought it might. Actually, I found very early on that the event really was not going to provide me with enough valuable information to stay through the entire event — so I left after the first presentation, as did the IT manager with whom I shared a table. What I gained had nothing to do with the event itself. Continued »
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 »
Establishing Application Requirements often seems to me to be a “which came first, the chicken or the egg?” scenario. Just where does one start when looking at a new application? What IS the “best” place to start? As an application developer, whether for a small business or a departmental application for a larger corporation, we are often asked to develop something from nothing. In my experience, what we are given to start with (if anything) is at best vague. Continued »
After Monday’s Blog Entry on “One-Size-Fits-???” I received the following from a fellow friend, associate and customer that is just too good to not pass on. (BTW — I did chastize him about not posting for all to see). He makes a very valuable point in his reply to me. Continued »
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 »
In a recent visit to my dentist, I had the experience of having the Xray tech “fit” an ungodly uncomfortable piece of plastic into my mouth for the xray. When I said something about how uncorfortable it was, her comment to me was “one-size-fits-all, which really means of course, that one-size-fits-none!” I’m not sure I agree with that statement, but the one-size that was used on me certainly didn’t fit.
Her comment started me thinking about how the statement applies to software applications.
I’d like to call special attention to one of the written principles contained in the “Agile Manifesto” relating to simplicity, “Simplicity–the art of maximizing the amount of work not done–is essential.” Yes, I agree with this statement. I also think that “feature creep” is a primary foe of simplicity, but that is perhaps for another post.
However, I wonder how many other developers such as I have experienced the “lack of simplicity” in creating software that is ultimately “simple” for the end-user. I don’t think that “simple” for the end-user is necessarily “simple” for the developer…and once again I turn to communication as a key ingredient. I find myself constantly asking the question “What will make this easier for the user?”
Fellow NEDC developer Garret Mott has published an excellent white paper called “Software as a Conversation“. I believe this is excellent reading for developers who are concerned about keeping simplicity in their application program “conversations”. Garret’s perspective in this paper can easily serve as a reminder to developers to perhaps “visualize” themselves as the user when designing.
What I’m getting at here is this — Let’s say you have users in your organization who need to have certain information — but the information is not readily available except on a paper form located somewhere in another location. You may realize this as a possible use for a document management system. Great! …Until you have priced it that is! “Buy” is NOT in the budget! Is “Build” an option? Can a custom designed program accomplish what you’re looking for? Might a “Build” option be affordable? …Or…Should you just ignore the need altogether and wait for the lack of information availability to “show up” in a dramatic way which might “raise some eyebrows” so that it will get attention? These issues I expect will come up on a regular basis in this blog.
I recently had the opportunity to visit a potential client to look at a
software development project that had been started by another developer
over a year ago. Just the fact that nothing was yet operational (nor
really functional to the potential user) was really a warning sign to me
as I looked at what existed. The entry screens looked like the forms
which the customer wanted to print — cluttered, and of course, far more
entry fields than would likely be used — very inefficient.