Skip to main content

Software Craftsmanship by Sandro Mancuso

Source: http://www.goodreads.com/book/show/18054154-software-craftsmanship

My first time to know about the term "Software Craftsmanship" is from Agile Tour Vietnam 2015. I finally read this book written by Sandro Mancuso who I met at this event.

Software Craftsmanship is a metaphor for software development: software as a craft and developers as blacksmiths. In other words, Software Craftsmanship is about professionalism in software development.

The Software Craftsmanship manifesto:
  1. Not only working software, but also well-crafted software: regardless how old the application is, developers can understand it easily; high an reliable test coverage, clear and simple design, business language well expressed in the code.
  2. Not only responding to change, but also steadily adding value: constantly improving the structure of the code, keeping it clean, extendable, testable, and easy to maintain; always leave the code cleaner than we found it.
  3. Not only individuals and interactions, but also a community of professionals: we are responsible for preparing the next generation of craftsmen; writing blogs, contributing to open source, making our code publicly available, becoming part of our local communities, and pair programming with other developers.
  4. Not only customer collaboration, but also productive partnership: software craftsman are not factory workers, they want to actively contribute to the success of the project, questioning requirements, understanding the business, proposing improvements and productively partnering with the customers or employers.
The Software Craftsmanship attitude:
  1. We own our career. "Who is in charge of our career and our professional future?"
  2. Keeping ourselves up to date: books, blogs, technical websites
  3. Know who to follow: help us to filter the entire amount of information we have online or in physical books.
  4. Practice, practice, practice: TDD, Katas, pet project(s), open source, pair programming
  5. Socialise: follows the manifesto "Not only individuals and interactions, but also a community of professionals"
  6. Deliberate discovery: the biggest mistake that we, software professionals, can make is not accepting that we don't know what we don't know.
Labels:

Comments

Post a Comment

Popular posts from this blog

Gzip upload on browsers

Today, I faced a problem that I could not upload my archive file with gzip format on Firefox, even it worked on Chrome. I was using macOS. My application had a setting to whitelist accepted files. I’ve already added "application/gzip" to that list. "It’s strange!", I thought. I finally figured out that my uploaded file's type actually was "application/x-gzip" on Firefox. I also asked my colleagues to check their uploaded files on Window and Ubuntu. Hmm… they were totally different! It was "application/x-compressed" on Window, and was "application/x-compressed-tar" on Ubuntu. In fact, gzip is already standardized by IANA. There is a note in RFC-6713 as below: "Some applications have informally used media types such as application/gzip-compressed, application/gzipped, application/x-gunzip, application/x-gzip, application/x-gzip-compressed, and gzip/document to describe data compressed with gzip. The media types defin...
2 comments
Read more

My must-have apps for daily work

There is no doubt that cool apps can help us be more productive and enjoyable at work. For the time being, I really love the following apps which are used by me almost every day. 1. A personal Kanban In fact, a personal kanban is the most useful app for me. Why does it matter? It is not just a to-do list, but it keeps me motivated every day because it helps me be able to know what my "big picture" is. I usually set up my plans together with a path to reach them.  KanbanFlow  is my preferred tool. KanbanFlow 2. A terminal Needless to say, a terminal is a must-have app for every developer, especially the ones use macOS/Linux. Due to its importance, I love to decorate and enhance it to be super exciting with various tools such as  iTerm ,  oh-my- zsh , and  thefuck . ;) iTerm + oh-my-zsh 3. A documentation "ecosystem" As a developer, I can not remember all things that I have experimented a day. Moreover, a document is really useful for sharing an...
Post a Comment
Read more

BIRT - Fix the size of an image

I use a dynamic image as a logo my report in pdf. At the beginning, I use table to align the logo in left or right. I meet a problem with some images with a large width or height. My customer requires that the logo should be displayed in original size. These following steps solves my problem: 1. Use Grid instead of Table 2. Set Grid "Height" is 100%  and "Width" is blank 3. Set "Fit to container" for images are "true". Download the the template here .
Post a Comment
Read more

Automating deployment and managing apps on OpenShift

Previously, we maintained OpenShift templates for deploying apps in development environments as well as delivering these templates to our customers for their on-prem deployment. Customers who refer to our templates (as well as documentation) have their own configuration management tools to automate the deployment such as ArgoCD and FluxCD. My son's buildings Our developers usually modify templates (YAML) directly on OpenShift for testing and then adjust the corresponding templates stored in the Git repository in Bitbucket. This sometimes causes an issue that delivered templates are incorrect because: - Developers forget to update the templates in Git repositories. - Developers don’t test the templates Therefore, our goal was to integrate a tool into our CI/CD that can automate and manage the configuration of OpenShift apps. The delivered templates should be the ones that are able to run on our OpenShift with the following purposes: - Automate deployment from templated in Git repos...
Post a Comment
Read more

DevOps Toolchain Enhancement

 Historically, our company ubitec had started with a customer project. Agile/Scrum was our proposal for working with customers. Time by time, Agile/Scrum also became our culture for software development. To be successful with this development approach, we somehow needed to have a fast release for customers (i.e. every one week). Back then, we had a build tool Jenkins which was responsible for having sprint release packages for our customers. The build job pipelines contain some steps such as gathering the artifacts, checking the code convention, running the tests, building docker images, and packaging an archived file (a zip file). The set of tools involved in a pipeline is roughly called a toolchain. It is just a part of a bigger process called the DevOps toolchain. Source: https://www.ibm.com/blogs/cloud-archive/2016/11/devops-architecture-available-on-bluemix-garage-method-site/ DevOps is a proven method that fits Agile. Today,  it is even treated as a mandatory factor...
Post a Comment
Read more