If there is one thing that is certain, doing more with less mentality has killed software development. Having a developer / programmer / analyst / tester / technical writer /etc., instead of multiple people to fill each each role, diminishes the overall role the SDLC (software development life cycle) plays in software development and maintenance. It does not mater what approach or methodology you use in getting software modified, there are defined stages in how software gets changed. I must stress software modifications, because new development in most companies is dead. Once the software is developed, it is maintained. Maybe it’s me, but most of what I read today about the various development methodologies focus on new development. Maybe maintenance is implied, but I think that most company leaders see the approaches as related to new development. This is simply not the case. The SDLC applies to change within the software and its related systems, not just new development.
If we dig deeper into each methodology, we can see patterns emerge that relate directly to the SDLC. Someone has to propose the change, specify the details of the change, make the change, test the change, and finally deploy the change. All stages in the SDLC that are well defined and have specific activities associated to each stage of the SDLC.A business case is created to define what software will be changed, why it will be changed, and gives high-level details on how much time and money it will take to execute the change. A user story, for example, defines the details of the change. A developer writes unit tests that determine how the code will react in specific situations. Testers will execute User Acceptance Testing to determine of the details of the change were incorporated as expected. Change Management governs how the change will be deployed into production, and what to do if the change does not go as expected. One other pattern emerges within the SDLC – a role is associated with each activity.
It seems unlikely that each developer / programmer / analyst / tester / technical writer / etc. is intimately familiar with each role within the SDLC. As Dustin Marx points out in his article, “[m]ost software developers that I know, especially the best ones, loathe worthless tasks”. This does NOT mean that there is no worth in each stage of the SDLC. On the contrary. It means that some are better suited for certain activities within the SDLC than others.
I have had the pleasure of working with one of the best analysts in the business (my opinion, of course). However, he lacks the appropriate skills to be a developer. He documents everything, and does it well, but he is not a technical writer, nor should he be expected to fulfill the role of technical writer. He has some understanding of system administration, but he is not a system administrator. The bottom line is – he is an excellent analyst, and there ARE people within the organization that CAN fulfill the other roles defined in the SDLC. Sadly, most companies expect each person within the IT organization to be all things to all people. This is simply unrealistic. As James Turner points out in his article,“maybe junior (or specialized) developers should be writing the unit tests, leaving the more seasoned developers free to concentrate on the actual implementation of the application”. The same can be said about believing that a developer playing the role of a data architect or system administrator or technical writer. It’s simply unrealistic to believe that each IT person has the same skills as every other IT person.
I guess the issue with roles goes beyond just playing a role, but communication. We all communicate to the nth degree, but most of the time it’s ineffective communication. It is a lack of understanding about what a role expects in the communication. Dustin Marx points out “It takes a very good meeting to beat having no meeting at all”. How often are meetings held to discuss a project’s health, only to result in “offline” meetings to discuss project health? I was always taught that meetings have agendas, meeting minutes are provided to outline what was said in the meeting, and what the tasks are assigned to each meeting attendee (aka action items). Again, without purpose given to the meeting, it’s just a meeting. Having the right roles in the right meeting is more important than having a meeting for the sake of having a meeting. And discussing the right details of the project, with the right roles, in the right meeting, trumps all reasons for having a meeting for the sake of having a meeting.
I will be overjoyed when the day arrives that business analysts have the proper amount of time to discuss software changes at length with the customer, developers focus only on writing code, quality assurance has the time to execute User Acceptance Tests ad nauseam, documentation is written by a technical writer instead of the power-user of the software, and the customer is tickled pink with the final product. Perhaps this is an unlikely set of circumstances to expect. Maybe the economy has tainted the view most have on the overall cost and value of IT. Maybe this tainted view has driven companies to the more with less approach to providing IT services in general. One thing is certain, IT support is needed within an organization that wishes to reduce the risks and costs associated with keeping records on paper. Delivery of quality software is more than just doing more with less, it’s about delivering what the company requires to do business competitively – at the right cost, with the right people, doing the right thing, together.