“Software Craftsmanship is about professionalism in software development”. It is about an approach to software development that puts emphasis on the coding skills of the software developers themselves. He speaks about Software Craftsmanship Manifesto where one not only creates working software or not only responds to change yet creates well-crafted software and constantly adds value.
The Software Craftsmanship Attitude:
This chapter stresses the importance of continual learning and self development. An individual has to take it upon themselves partially to progress towards bettering themselves. Coders can’t rely on employers to teach them everything.
Software Development Nowadays:
Seniority is software development has no correlation to one’s skill set. The number of years one has worked is a poor indication of their ability to write code. “There is a huge difference between having ten years of experience and having one year of experience repeated ten times.” The need to explore different technologies and project is vital in this field. The industry is adapting towards needing more flexible coders.
After the author goes over the principles of Agile manifesto, he says the statement “Many Agile projects are now, steadily and iteratively, producing crap code.” Roles became reversed, and everything was a mess working in an agile environment. It has been a partial transformation in his words–or a transformation of the process but not of the technical practices. Software Craftsmanship is not meant to replace agile but to assist it.
During Sprint 3 we were able to complete our small tasks, but upon approaching our first bug we ran into a problem where we could not locate the button. The problem description was not very descriptive and contains no images of the said button. There was a section with forms on the site that we were assuming contain the button (due to the name of the button having ‘form’ in it), however none of the forms would load on any of our computers or servers. We reached out to the product owner and received a response toward the end of the sprint where he provided a new server. With this new server we were able to load a form which corresponded with us finally being able to find the button. Using debugging tools in the browser we can easily find the code name of the button and the container allowing us to easily find the section of the code that we need to change. Sadly because of the delayed response and how much in class time we have we are going to have to push this item onto the next sprint.
Teams and Projects:
Teamwork doesn’t happen nor flow instantaneously. Teams need time to adapt to each other and learn to work and flourish as a group. Therefore breaking up a team for projects is a terrible idea. This idea was very fitting because our group started off working very poorly together–or more so we just didn’t collaborate. Over time we are beginning to adapt and be more vocal.
Mentoring, Apprenticeship, and Craftsmanship:
New programmers need mentoring. Like any other field, becoming a specialist most of the time takes years. Given the impact of software on our lives, this is crucial. There is no responsibility for elders to teach the young causing a missing puzzle piece in programming. It’s producing a lack of role models.
Pressure can make or break people. There are some who thrive, some who fail. The professional developer is calm and contained under these circumstances, sticks to their roots, and finds the best route to hit the deadline. However avoiding pressure from the start would be the better option; do not make a promise you cannot keep. In other words, only make a commitment you can fulfil, keep the code clean, have a plan, and work in a way that there is no need to change it during a crisis. In relation to our class, we are under pressure during our sprints to finish what is on the table. If we accept too much, we might not be able to finish making us look worse.
The majority of programmers prefer to work alone; that’s just how it is. There needs to be a common understanding for communication amongst the business folks, clients, dev team, etc. Collective code ownership and pairing create this level of communication that is necessary.
Overall sprint two went well. Our basic Trello tasks were completed which included setting up, connecting, and building our APATH login. The main issue that arose with connecting to AMPATH was the server on the site; it wouldn’t allow any user to connect normally. Therefore either the user could download a chrome extension, which for some of us caused our Wi-Fi to crash, or add a code snippet to one of the xml file. Option B proved to be the more promising choice that most of us went with. Some of us were able to begin rewriting some of the module, nothing too special yet, but it will still be placed onto the backlog of the next sprint.
A big part of our retrospective was that we realized our communication and teamwork has been rather poor. Up to this point, the majority of the work has been done independently which we believe to be partly caused by nothing has been too extreme or challenging that we have had to collaborate on, but nonetheless we are looking to improve in those aspects come the next sprint. On the other hand we have had some issues with attendance and participation in daily scrums that we addressed and hope will be fixed for the next sprint.
Time management is key to accomplishing most tasks in life especially programming. Time is precious; do not waste time. Meetings are necessary, but often are time wasters. Keep discussions brief within meetings, try not to keep everyone there trying to solve a problem in the meantime. Keeping focus all the time is a tough task, especially with software development, but you can break up your day with simpler tasks. This directly applies to us but more in the sense of managing other classes/work on top of our programming.
Estimation will always cause uncertainty. One of the hardest questions a developer will ever have to answer is how long something will take. The PERT technique computes distributions based off best-case, nominal, and worst-case estimates for the project.