Software Craftsmanship

Agile software development and software craftsmanship.

 "Uncle Bob" Bob Martin who has being a software developer for 4 decades,  has a company object mentory where he helps teams accept and addapt agile process. Had tried being an Architect but after a while he had realized he likes writing code as much he can. Through a podcast he had a conversation with Markus to reveal some truths about programming, craftsmanship, designing, agile programming, etc.

 In search of efficiency coding, producing quality code fast is vital.

 In this podcast Bob Martin introduce us with the notion of craftsmanship and declares a big statement
about documentation, sometimes we believe an agile team does not produce any documentation, this is false there is no reason why they can´t produce documentation, if they need an UML diagram they used it. Bob states "The main documents it´s code itself, all other documents are reflections of this main document." The relation between programmers and architects is manly wrong in the industry, some architects believes they should be closer to the enterprise side forgetting about code, how will an architect design and "lead" a craft he doesn´t see.

 But what is software craftsmanship?
Software craftsmanship states that rookie programmers should learn from the masters who will mentor them until they can settle down and really understand their craft, seeking to become masters.

 The whole idea of craftsmanship is the the idea that you learn from other people by helping them do. Just like the path of a blacksmith where you learn by crafting and with help of other more experienced blacksmiths. In craftsmanship you are not just proud of the the craft you build you are also proud the way you build it. You look at the code and can be proud of the result you can be proud of the structure within
References:
http://www.se-radio.net/2009/11/episode-150-software-craftsmanship-with-bob-martin/

Comentarios

Publicar un comentario

Entradas más populares de este blog

Hidden Figures

Hidden Figures For me was unexpected to watch this movie on class, it surprised me a lot the way that address several topics that happened on the USA around 1960: the racism , the cold war, the launch of the Apollo 11 and of course the arriving of men on the Moon. I decided to divide this blog in three sections, to tell from my point of view this topic and how it's related with the movie. It's not a mystery the United States have always suffered of racism, an evil they have never being able to eradicate. The situation today is really different from the one lived on 1960, hidden figures portrait it in a close look on how those years were. Imagine being a woman and black in the late 1960, just 12 years have passed since women can vote, sexism is still predominant. Here is where Katherine Johnson, Dorothy Vaughan and Mary Jackson going against all adversities achieve individual success contributing directly on the success of the USA and of humanity itself. The cold war was
Leer más

The 4+1 View Model

The 4+1 View Model Developed on 1995 by Philippe Krunchten. This model break down the whole into sets of related parts. Is composed of the Logical View, the Process view, the Physical view, the Development view and the Use Case View. Logical view: Shows the parts that comprise the system it describes the system object model. And it has the following UML's: Class diagrams, state diagrams, object diagrams, sequence diagrams and communication diagrams. Process view: Describes as system´s processes it's UML is the Activity diagram. The Physical view: Maps software artifacts onto the hardware that hosts them. It has the deployment UML diagram. Development view: Gives a building-block view of the system which is composed of  system's modules, or components, including packages, subsystems, and class libraries. It uses the component UML diagram and the package diagram. Use case View: Show the system functionality, is helpful in defining and explaining the structure and
Leer más

Is Design Dead?

It seems that XP calls for the death of software design.  Planned vs Evolutionary Design  Evolutionary design: "The design of the system grows as the system is implemented".  The benefits of Planned design are varied just like the disadvantages that some XPers use to justify choosing XP instead of Planned. The author mentions the following disadvantages: You can't think all the issues you'll encounter when programming.  Designers are so busy designing they don't get much time to code any more.  Changing requirements. You can deal with the changing adding flexibility into the design to enable an easy change of requirements. One reason in favor to simplicity is economic. Doing work that's only used for a feature needed for tomorrow means loss of effort and so of money. Another reason is that a complex design is more difficult to understand than a simple design.  In  XPE  Kent gives four criteria for a simple system. Runs all the Tests  No
Leer más