Software Development and Direction
This has come to light recently. No specifics but I will try and give my point of view on this. Recently I have been informed of a software project where the requirements are gathered from the “customer”. OK so far so good. The customer no matter the project is the one who outlines the problem to which the solution will be provided to.
Then these requirements are then defined into a solution, which will be developed. This sounds like the standard way most software development happens. Long ago, while study at university these concept were drummed into us. Here is the problem, define the solution, develop, test and release. Disregarding the typical development methodology utilised with this, when defining software and how it will work this is much like it. But I am not looking into the way in which this information was then presented to me.
Once the problem was describe, gathering the requirements, define the solution, then…
This is where what was told to me, feel down. No one was taking ownership of the project. The group would sit down and nut out the details, fine, define the elements to be developed, OK. This was it, nothing more other than the talk on the delivery. Whom allocates the resources, whom defines the milestones (not in a typical sense, but we much hit deadlines for various elements), whom decides we are heading in the right direction based on the requirements gather. This is where everything I knew about software development fell down.
This is a small team, developing software that is for a very niche market, it happens and this is often the way of things in small companies. But, there needs to be a clear goal (which is the requirements for the customer), but there is no one pushing for the end goal, there is no one making sure that the deadline (this is the end deadline) is going to be met.
This is a crude diagram describing the way software is developed. One might say, that with all of the various methodologies around this is possibly older. But since I am not getting into the nitty gritty of each methodology and the pros and cons, I am simply describing what has been told to me. Baring this in mind, it seems that there is going to be no one who is going to guide the ship. Even when looking at Agile or SCRUM there is someone who is monitoring the progress, someone who oversees the project.
I have also been informed that this is also a make or break stage, understandable, but in reality not practical in the long time. One can’t truly get the best from people when people know that if there is a problem they or the project is in jeopardy of failing. I find that one of the biggest driving forces for software developers is tangible results, developing a solution that will never see the light of day, being thrown work that is not in the best interests of the developer as they do not work to their strengths but also not in the best interest of the business as they are not maximising the resources to their fullest.
I will post some updates over time on this to give some information on the progress of this. But one might see that depending on the end outcome I may have a lot more time on my hands to talk about the failings, if it happens, or perhaps when.