Mastery as a Lifelong Endeavor

While I think that it is relatively straightforward to begin the software development journey, it is another thing entirely to become a master. Mastery is nearly impossible to measure and may require a lifetime of dedication to the craft to achieve. While these facts may be almost universally applied to any craft, I think that when applied to software development in particular they are especially telling. In Hoover and Oshineye’s Apprenticeship Patterns, they discuss a pattern termed The Long Road. It is this Long Road that is representative of the lifelong journey that is mastering the craft of developing software.

Hoover and Oshineye urge that the true value of mastery lies not in making more money or gaining status and power, but in, “comprehend[ing] and appreciat[ing] the deeper truths of software development.” This focus on the craft rather than on typical indicators of success such as promotions or high salaries is what sets truly great software craftsmen apart from the mediocre. I found it both inspiring and a bit comedic that Hoover and Oshineye included the parts about surpassing legendary software craftsmen such as Donald Knuth or Linus Torvalds. When you think about it, however, such feats do not seem entirely unrealistic considering that anyone truly hoping to become a master software craftsman will likely dedicate over forty years to that end.

I feel that this pattern would likely be offensive to developers who chose computer programming simply because of the abundance of jobs or relatively high starting salaries, not because of a genuine appreciation of the craft. These software developer posers would have no desire to become masters of the craft, and would jump ship at the first opportunity for a promotion or raise. This is also where the lack of knowledge transfer between generations of developers mentioned in the pattern’s introduction originates. If developers are waiting for any opportunity to move on, then the void that they leave is constantly being filled with new developers, leaving few veterans to show them the ropes.

I can certainly appreciate why a promotion to project lead or some executive position would be a tempting opportunity for career advancement. These roles, however, often require giving up the very things that make software development such an exciting and rewarding job to begin with. The feelings of pride and excitement after finally figuring out a difficult piece of a program or passing every test case is something that software craftsmen on their journeys to becoming masters will continually experience.

Choosing a CMS

When choosing a content management system (CMS) to begin developing a website for myself or someone else, there are a few important considerations that must be made:

1. Who will be maintaining the website after development is finished?

I think that possibly the most important consideration that needs to be made when choosing a CMS for website development is who will be the one responsible for maintaining and updating the website once development is complete. Nothing is more frustrating than going on a beautifully designed website only to be faced with outdated and/or broken content. It does not matter how beautiful or complex the original design is if there is a need for dynamically updated content and nobody around who possesses the skill set required to make the changes or update the content.

2. What type of website is being built?

Another important consideration is the type of content that the website will serve. While many CMSs have support for multiple types of websites such as blogs, ecommerce stores, and static content sites, one may be better suited to a particular task than another. Choosing the right CMS for the job can make both the developer’s life easier and also create a more efficient, polished finished product.

3. How is the website being deployed?

In addition to considering how the website will be hosted and deployed, it is important to consider what the expected volume of traffic will be when choosing a CMS. If the expected volume is extremely high, then perhaps a cloud-based SaaS CMS is the best option. A cloud-based solution would allow for much easier load distribution and balancing and may be automatically handled by the platform itself. If volume is expected to be relatively light or the site is to be hosted locally, considerations must be made for the hardware/software support of the systems on which the site will be running.

4. Does the website need to integrate with existing infrastructure?

In addition to hardware/software considerations for deployment, another factor to think about is what types of IT infrastructure is already in place that will need to be integrated into the website. If there are already databases in existence, ensuring that the website will be able to integrate with them will save significant time and cost over having to migrate data between systems.

5. What kind of support is available for the CMS?

Whether it is for the developer, or for the client after development has been completed, what types of support and how easily accessible it is can be an important factor in deciding on a CMS. Are security patches regularly released so that the site will not be vulnerable? Is there a community that releases plugins, themes or other types of time-saving customizations for the CMS?

In deciding on which CMS to use for the development of the Massachusetts HOSA website, I considered these five points and decided on WordPress. My experience with WordPress as a CMS has been very positive, and I feel that choosing such a user-friendly CMS will allow for straightforward updating and maintaining of the website for many years to come. WordPress is flexible, powerful, and will be easy to scale should the needs of the organization change in the future.

Which Came First… The Test or the Code?

In episode 31 of a podcast by Brian Okken on his show titled “Test and Code,” Brian has a discussion with guest Paul Merrill about the testing pyramid and why he is frustrated with certain test-driven development (TDD) models. The discussion began as a Twitter disagreement between the two test enthusiasts and blossomed into a full-fledged “civil discussion.” While both Brian and Paul agree about the importance of testing and see the value in test-driven development, they disagree about how extensive testing needs to be in order to be effective. The two also disagree about how tests should be written and to what extent code should be based on testing versus tests written based on code. Although they do not seem to ever reach a consensus on the issue, each of them make some excellent points and give examples of personal experiences to support their opinions.

Brian, for example, is fed up with the sheer number of redundant unit tests that are written to test the same thing in traditional pyramid testing. Brian presents an example of a hypothetical method that has a test written for handling negative numbers, but the higher-level method that passes values to the first method will never pass a negative value. Brian sees testing the first method’s ability to handle negative numbers as unnecessary and a waste of time. If these same types of tests are written for hundreds of methods, Brian argues, an extraordinary amount of time is wasted on useless testing. As a rebuttal, Paul argues that if changes are made to the higher-level method that allows negatives to be passed down, the tests would already be written. Clearly not convinced, Brian scoffs at this justification for the test he clearly sees no value in.

Paul seems to have some sort of personal experience in all of the obscure areas that Brian dismisses as rare or unusual scenarios. Paul seems to support a bottom-up test-driven development platform, where tests are written that outline how every last detail that a program will perform. Paul argues that this is the best way for tests to effectively drive development. He seems to think that tests are not able to aid in the development process if they are written after development has taken place. Brian, on the other hand, sees this issue from a top-down perspective. He argues that higher, user-level tests should be written first. When the high-level tests are insufficient to further drive development or are too ambiguous to write code for, then lower-level unit tests should be written.

It was extremely interesting to listen to two experienced testers discuss such a controversial topic. While I can see where both men are coming from with their opinions, I seem to lean towards Brian’s side in the argument over test-driven development. I think that the points he makes about a pragmatic approach to testing is important. Rather than generating some ridiculous number of unit tests that may not have any bearing on the actual functioning of the program, the effort should be put into doing what was originally promised by the program specification. I think that I will follow Brian’s advice and also take the pragmatic approach to writing tests, in the hopes of avoiding rewriting tests and code. In the end, its not about how many tests can be written, its about testing for the correct things in order to deliver a bug-free program.

Is ‘Agile’ really agile?

The Agile software development methodology is based on the “Manifesto for Agile Software Development,” which outlines the values and goals of the platform. For many software development teams, an Agile methodology has replaced the dated Waterfall method. I think that the diagram below does an excellent job of highlighting the key differences between the two methodologies.

(Image source: https://www.seguetech.com/waterfall-vs-agile-methodology/)

The Agile method allows developers more flexibility and involvement in some of the stages of the development that were previously dominated by managers and other higher-ups with no connection to the code itself. In cases where getting a working prototype of a project deployed quickly is of primary importance, the Agile method is the clear choice. In Agile development, responding to changes in the program specification can be done relatively simply through regular meetings and discussions of progress.

The more traditional Waterfall methodology follows a linear sequencing, where each step must be completed in order before the next step is begun. This means that there is often a longer period of development before any product is ready to be deployed. When the product is deployed, however, it will often be more polished and complete. The Waterfall methodology does not respond well to changes in the specification, as this will often require backing up in the process and then reworking each of the steps.

Now, with a general idea of the two methodologies, I could begin to understand where user ayasin is coming from in his rather intense post titled, “Agile Is The New Waterfall.” The post on Medium.com generated quite the buzz of controversy, and even attracted the attention of well-know computer science figures including Uncle Bob. In his post, ayasin argues that Agile has become the tiresome, outdated successor of Waterfall. While he does not offer any solutions, he sure presents a lot of problems with Agile. Ayasin describes the Agile development process as follows, “You just throw stuff together as quickly as possible because you know it’s mostly trash anyway.” This hardly seems like a way to produce quality software. What’s more, ayasin argues, is that more of the responsibility (and potentially blame) is placed on the developers themselves, as they are given the illusion of involvement in the process without any real control of the outcome.

Before finding ayasin’s post on Medium.com, I had a vague idea of the Waterfall and Agile methodologies. After a bit of research of the two strategies, the post seems to make some excellent points. While I agree with some of them, I’m not sure if ayasin is being a bit harsh on Agile. It would seem that when properly implemented and followed, the Agile methodology has significant advantages over the traditional Waterfall method. Reading about the two methods has given me insight into some of the challenges I can expect to face when working on a project in the future. I feel nervous but prepared for these potential challenges and look forward to someday working on projects like the ones described in my research.