Software, Software Development and other Atrocities

I've been marking assignments for a week now. This is so mindnumbing... I will never be a lecturer!

In recent years many agile methodologies have been created to respond to the weaknesses of the traditional or waterfall life cycle methodologies.

The main philosophical underpining of the agile methodologies is to walk beside organisation's evolution. As modern organizations evolve and adapt to their environments rapidly so should software development.

Traditional development methodologies (waterfall lifecycle) were created upon the assumption that requirements never change. Software were created based on a snapshot of the organization's situation. Projects (price, time and design) were planned in advance and any deviation from them were considered a mistake which had to be corrected.

Agile methodologies are based on the assumption that organisations, users, and their requirements change. Agile methodologies are designed to adapt to changes: they are selfadaptive. To achieve that, users and developers work together and expect change all the time. Requirements, specs and code are reviewed constatly and changed when necessary. The aim is for a good quality software that meets the needs of the clients and not for meeting the deadlines and not running over the budget.

Today I've been reading blogs and forums about agile methodologies. So far this is what I've been able to gather:

1. Agile methodolgies prefer "Responding to custumer feedback" strategies reather than "Planning ahead" ones.
2. Agile methodologies are suitable for Incrementalists/realists kinds of developers. Incrementalists like to split software in bits and develop the most important bits first. They have an idea about what is achievable in real life in a certain period of time.
Traditional methodologies prefer Completionists or idealists because they can see the "big picture" (but fail at implementing because they have to account for every single detail in the design). In traditional methodologies every step has to be finished before attempting the next one.
3. Agile methodologies require more flexible customers capable of dealing with "uncertainty". Customers will receive the software in bits and will not have an idea about how the final will look like until the end of the project. They will give feedback to developers constantly and will work with them to decide on the course of actions.
On the other hand some developers say that agile methodologies are more "predictable". This is because it is more probable with agile that the final result will meet the customer needs. With waterfall one cannot predict if the final product will meet customer expectations, especially because the specifications are written so much in advance. One learns new and important things as one progresses in the programming.
4. Agile (XP), is not a cheaper alternative to waterfall. It was created to provide 100% customer satisfaction, that is, the customers gets what s/he wants. The final product is "good enough" to satisfy users.
5. Applications developed with agile approaches are more flexible and less resistant to change because of the constant additions and refactions during development time.
On the other hand because of constant change there is code in the applications that is no longer being used but rarely removed.
6. Agile works best in corporate solutions or business applications with big databases, where users can be consulted as opposed to shrinkwrap applications which can be more generic and where there are no users to talk to.
7. Agile are better fitted to ill-defined problems.
8. In agile methodologies design and coding are merged.
9. Most agile methodologies don't address maintenance which according to some (Boehm) is 80% of the SDLC.
10. There are two types of documentation, documentation for now (first development) and documentation for later (maintenance). IMO some agile methodologies like XP consider only the first type and neglet the other.
11. Most used techniques in agile methodologies -> pair programming, refactoring, test driven development, nunit testing... By the way, pair programming is the most mentioned by advocates and retractors. Some developers feel their productivity increases when they work in pairs, some others find it difficult to work with other people.

Hace un rato escribi un mini ensayo a cerca de algo que me pasó hoy en la mañana. Resumiendo, algunos estudiantes me agotaron la paciencia + terminé cansadísima después de la clase e incapaz de pensar hoy en la tarde. Tengo mucho trabajo que hacer en mi doctorado y me da colera no poder avanzar. Justo en este momento estoy analizando datos, pero mi cerebro no me da. Decidi borrar el ensayo, siguiendo el consejo de un viejo.... amigo. (mas sabe el diablo por viejo que por diablo). Parece que el ensayo estaba un poco... fuerte. Ejem.... la vaca no se acuerda cuando fue ternera. Cuando era estudiante de pregrado o maestría me parecia muy fácil quejarme de los profesores y de los tabajos (que en realidad son un chancay de a 20 comparado con el doctorado). Ahora que me toca enseñar ya se lo que se sufre para hacer que un estudiante aprenda, sobre todo los que no estan motivados (y tambien los brutos).
Ya se que la audiencia de mi blog es 1 o 2 personas, pero aún asi decidi borrar la entrada anterior... no vaya a ser que en algunos años me haga famosa y alguien me lo saque en cara. :p

Me voy, creo que ya me esta entrando la inspiración.

I started my PhD thinking on Decision Support Systems (DSS). I’d been working on one in my previous job. Having found so many difficulties while gathering information (interviewing people and reading documentation), and designing the system, I thought that it was a good idea to investigate better development practices to do this. My initial work was on describing the kind of settings I had found during my years as a developer. To do this I first identified the problematic factors that made analysis and design so complex. This is what I found:

• There was a great variety of activities. Those varied from academic related issues, like module planning and student complaints to administrative issues such as budget preparation and marketing promotions. There were a number of people who combined their academic and administrative functions in an unclear fashion.

• Users performed similar processes in different ways among the university areas. The personal styles that dominated shaped the development of the processes.

• Processes changed through time specially when the authorities of the university were replaced.

• A decision making process may be initiated by any member of the administrative or academic staff in the university or by students.

• The nature of the problem and the working styles influenced the way people would carry out the decision making.

• Most of the processes involved flow of a huge variety of documentation like reports with information extracted from the databases (tables, charts) but also of documents containing unstructured information such as texts with decision makers’ opinions and decisions.

• Users worked alone, in groups or in multiple groups depending on the convenience and availability of the interested.

• The university board and other committees meetings were, in some cases, the last stage in the process. However, most of the hard work was performed before they met.

• There was a requirement of recording all the data resulting from the decision making processes that were carried out at the highest levels of the university, as it was specified in the university regulations. However, this need was also perceived in most of the medium level staff as they believed that this information may facilitate their work in the future.

• Information was required in most of the stages of a process.

well well well I got bored..... zzzzzzzzzzzzzz

To be continued…

I’ve done software development most of my professional life. Now I am doing a PhD in the same topic. It is a challenge, but it is also rewarding. When I started I had no clue about how to develop an idea worthy for a PhD nor did I have a clue about how to investigate it. Thankfully, I found my way through it. I decided to study the social aspects of business organisations that affect the process of software development. To do this I designed a qualitative research. As I am very fond of internet and computers (and not so much of libraries, books and essays), I planned an online ethnography on software developers, where I could chat with peers about their problems at work. Now, I have finished my fieldwork and I am doing data analysis. I guess that it will take me two months or so to finish it. After that I will start to write my thesis.

I will use this blog to tell you about my life as a PhD student, to comment on my findings about complexities in software development and to share my experiences at doing online ethnography.

Hoy, 04 de abril de 2005, día memorable, en el cual inicio un blog memorable, (ejem, ...eso espero)
Today, 4th of April 2005, I start this (I hope) memorable blog.