Category Archives: Week-2

YAGNI: Because More Isn’t Always Better

YAGNI stands for “You Aren’t Gonna Need It”. This is an acronym I’ve only taken to heart recently, despite reading about design principles on and off over the past few years. I have learned enough from my mistakes in the early days of programming to know that planning pays off, and what could be better planning than adding code now to help yourself add things in the future? Two words: clean code.

This summer, I was tasked with designing and implementing a desktop application from scratch, as the only developer. The specification was vague (essentially, “these are the user inputs, this is the output, and leave room to add more inputs and outputs later”) and it required research into topics that have nothing to do with software, that I had never seen before. This caused me to create unnecessary abstractions and extra features in many places, just in case. In the end, I refactored quite a bit once I understood more about what was required and realized what wasn’t needed. The extensibility that I actually needed worked out great. Everything else got in the way.

A blog post on YAGNI by Martin Fowler does a great job of describing what I did wrong, and I chose it in order to learn how I could have improved what I did. His summary of YAGNI is that features you expect to need should not be built. Features should be built only when you actually need them, because it’s very likely that “you aren’t gonna need it”.

Fowler goes on the describe the main argument YAGNI makes, which is that you might be wrong about presumed features. When you’re wrong about features, you accrue four costs: the cost of building a presumptive feature, the cost of delaying other features, the cost of carrying the presumptive feature (making it harder to modify other code), and the cost of repairing the presumptive feature (because even unused features must be maintained).

One major point that Fowler stresses is that this does not apply to efforts to make code extensible, unless it adds unneeded complexity. There is a difference between adding code that is easy to refactor in the future, and adding unused code. The former follows other design principles. The latter adds clutter and creates confusion. And who needs more of that?

Could I have done better with the aforementioned project? I think so. There were a couple major overhauls that would have been a nightmare without some extensibility baked in, but most of that code didn’t add unnecessary complexity and is therefore in line with YAGNI. I also have to consider that it was a single-person project done in 3 months, so it is likely that the negative side-effects were kept at a minimum. It’s also impossible to determine how much time I spent searching through unnecessary code, so a little more YAGNI could have sped things up. In the future, I’ll be considering this important design principle.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

UML Diagrams

Many times, people go into projects without much planning
before-hand which can cause many problems to arise. UML class diagrams can come
to be your saving grace. With these diagrams you are able to plan out how the code
will be set up down in a neat organized diagram. In these diagrams, the top section
depicts the name of the class, the middle section depicts the attributes and
the bottom portion is what lists the methods of the class. The top section will
be bolded to indicate that it is the class name. This top section however can
say whether or not the class is abstract, concrete or an interface. If the name
is simply just bolded, the class is concrete. If the title is italicized, then
the class is abstract. If the class is an interface, the top section will have
the class name bolded and <<Interface>> listed above the name.  In these middle sections you are able to
specify a lot about the attributes of the class. Any variable will be listed
with a minus sign beforehand and the data type following. If any of these
variables are static, then they must be underlined. This allows for someone to
seamlessly set-up the class without having to worry about including the correct
variables and data types. As stated before, the bottom section will contain the
methods of this class. These methods will contain the name of the parameter (if
applicable) and the data type of that method. If the method returns a data
type, this will be listed after the parameters. UML diagrams don’t stop there
though. What I was describing was one box/class, while UML diagrams can contain
many, with indicators to show the relationships between them. Arrows are used
to show relations between classes. An arrow going from one class to another
with a hollow white tip stands for inheritance. When an arrow is going from one
class to another with a dotted line, that represents implementation. A solid
black arrow means there is a reference from one of those classes to another. By
using UML diagrams, you are able to set up one’s entire program before writing
any actual code. This allows for anyone else to be able to read and understand
the code by simply going through the diagram. UML diagrams gives the coder the
ability to write clean flowing code. Below is an article which goes in depth
more with UML diagrams and also gives examples.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Continuing Platform Comparisons

Last week I continued researching the features of the GitLab Gold and GitHub Free platforms. I continued going down the list of the features listed for GitLab Gold on its feature comparison page and then seeing if GitHub Free had similar implementations of these features. I originally thought that most of the GitLab Gold features would be exclusive to this platform, but to my surprise GitHub Free supports quite a few of GitLab Gold’s advanced features. I found that GitLab Gold does have some features that GitHub Free doesn’t though, some of these are either advanced features geared more towards enterprise environments, others seem to fall under more advanced user permissions such as selecting which users can approve merge requests. I found that GitLab Gold’s issue board system is much better than GitHub’s project boards with the ability to create more advanced boards than GitHub, such as a board with user assignee lists or a milestone list. I am again finding that certain features between the GitHub and GitLab platforms are easily comparable and have a direct counterpart such as requiring commits to be signed and other features are a bit more ambiguous such as supporting what GitLab calls “backlog management”. I am finding this is largely due to how clearly GitHub’s and GitLab’s websites document and explain the features the platforms offer. Another thing that I am finding that makes this comparison process harder is that the description for the feature on GitLab Gold’s product comparison page doesn’t always match exactly with the features described in the documentation it links to, or sometimes the links provided from the feature comparison page don’t go to a specific section of the online document. I have also begun to use the test groups to see for myself what features are available in these platforms. I have been mainly using the GitHub organization to compare its project board features to GitLab Gold’s issue board features as I find it is easier to actually see what’s available in GitHub than to use its website guides. I have also started to take note of what I think should be tested in the workflows between GitHub and GitLab, this includes the project/issue boards and some of the more advanced options GitLab Gold offers, along with other user permission settings GitLab has such as push rules.  I am hoping that at the meeting later this week we will refine the workflow so I can begin testing these features. I plan to finish the comparisons between GitHub Free and GitLab Gold before the meeting at the end of this week so that I have a good idea of all the advertised features of all of the platforms.

In addition to continuing research on the platforms, I also began to learn more about the LibreFoodPantry project. I did this by going through all of the past meeting minutes that were sent to me. I wanted to get a better idea and background on the project to see what decisions have been made so far and how my research into version control software fits in to this. I also wanted to this before the meeting later this week, so I could get a better idea of my purpose in these meetings.

From the blog CS@Worcester – Chris&#039; Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Your First Language

Hi dear readers. Welcome back to my blog. From now on I will be writing for different Apprenticeship Patterns that I will find interesting in the book to share with you.

I started computer science with 0 knowledge in coding, programming languages or anything else related to this world that I find beautiful nowadays. My very first programming language was the famous Java and not because it was my choice but because my first contact with coding was in Intro to Programming (CS-140) and the teacher had chosen Java as a language. Now that I think back three years ago, I am happy that I started my software craftsmanship with Java.

A summary of ‘Your First Language’ Apprenticeship Pattern would be that if you start your journey different from me (in the meaning that you can choose your first language), the book recommends you to research about it and try to figure out what is the most suitable language from you. It doesn’t have to be one of the most popular language but as every language has its own characteristics you got to pick the one you find more easy (or hard, if you like to challenge yourself). If you don’t trust your research skills than you can ask your friends who are familiar with programming languages and they will  be able to tell you the differences between a few languages and why they like what they like. Learning the language is not the only step of the process as you will be using this language forever to solve different problems you might come across. Remember, switching is always an option..

Most of my friends had started programming with Python which I have heard is a very easy language to learn and use. I remember when I started to learn Java I used to try and solve other problems (as much as I could) so I would get practice and in my first problems I was not using any other libraries. Practice is the key, believe me! A language is easy to learn but it has a lot of volume. Once my boss said: “Its not the language we should memorize, its the data structure” and I totally agree as in your journey you will work in different companies that will use different languages.

I really like that this is the first pattern included in the book as the first language is the first contact you have with coding. And don’t forget..Practice 🙂


From the blog CS@Worcester – Danja&#039;s Blog by danja9 and used with permission of the author. All other rights reserved by the author.

Your First Programming Language

Hi everybody and welcome to another blog post for CS 448 Individual Apprenticeship Patterns. Today topic is going to be about one of the patterns in Individual apprenticeship patterns which is your first language. I learned a lot from this pattern like obtaining my first job will depend on my proficiency in a specific programming language. I started after reading this pattern to focus on one specific programming language which is swift. I chose this language because I been reading other articles and pattern that say to work on something, I going to be passionate about which is creating a fun application. The pattern advised me to become fluent in it, so I been coding problems and reading more about the language daily. I also feel more comfortable after reading this pattern when asking for help. I have always been too embarrassed in the past to ask for help because I felt like I should know how to solve the problem but now I will try to be more open with some of my programming errors but only if I desperately need it. The pattern talks about playing around in an environment with topics that I’m unfamiliar with which I totally agree with. XCode has an IDE call playground where I been just messing around with unfamiliar features and language. I have also been reading more about a testing framework after reading this pattern. I found this pattern helpful because I realize that there are many ways, I can improve in my programming skills. I learned that my first language is very important as a beginner programmer because the first language is going to be my building block for my career and foundation for future language that I will soon be learning. I think after reading this pattern your first language I really change the way I work and code. I have been more motivated to get a strong understand of the language I decided to invest in the most. I found this pattern interesting and I never knew the importance of the first language before because I been using every language and wasn’t focusing on a specific language which causes me to be decent in all of them instead of being proficient in one. All in all, this pattern was very inspiring.

From the blog CS@Worcester – Phan&#039;s CS by phancs and used with permission of the author. All other rights reserved by the author.

Beyond the point of no return?

For the second week of reading, I chose to read the pattern, A Different Road. This is a continuation off of Draw Your Own Map and discusses an issue. The issue is when you have followed your own path as a software developer and hit a road block. This road block is not about whether or not you could become better and rather that of a change in interest. It details the possible outcome of leaving the industry to pursue another interest and what could happen upon returning. There is a chance that the gap from working in different industries could work against you in the end. It is said that some organizations will deem the inactivity from the field as suspicious and will question your return. The risk is big, but it is still important to follow your road map where ever it leads.

What I found useful about this pattern is that it encourages others to follow their hearts or road map that led them up to the decision where they might be leaving the profession. Everyone only has one life, and usually the saying is to do what makes yourself happy. Sometimes, people need a change of pace and it’s important to recognize that. However, I am not surprised that some organizations will question your absence from the profession if you chose to leave for a while. I’m sure many of us who chose to study computer science has realized the type of field we are going to throw ourselves into. Another interesting part of this pattern is about the work experience between two different jobs can sometimes be used effectively. Depending on the context of course, one experience in a separate field may be used to fix or provide a solution to a problem in a different field. This also goes back to the organizations who might disregard any experiences that an individual has that isn’t related to the experience needed to fill the desired position. I feel that the only choice after leaving the long road for a while is to work twice as hard to get back in. Lastly, I do believe there are probably plenty of ways to accomplish that and it’s not a lost cause overall.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Be the Worst

As I mentioned in my last blog post, I have a bad case of impostor syndrome and oftentimes get discouraged when comparing myself and my work to more experienced developers. This week’s apprenticeship pattern helped me understand that being farther behind on a stronger development team with intent to catch up (a small fish in a big pond) can be more beneficial than being more of an outgrown member of a team that doesn’t challenge me as much (a big fish in a small pond).

“Be the Worst” describes the problem of plateauing in new knowledge, as the apprentice continues to work in a team that doesn’t push them to challenge themselves. As a result, the apprentice may start to grow out of the team. The solution is simply for the apprentice to look for opportunities in stronger teams. By establishing themselves in such a group, the apprentice should be more motivated to work harder to catch up to the level of their teammates. While this poses a risk of potentially falling even farther behind, it has the immense reward of learning more, at a faster rate.

This section definitely reassured me that even if I am farther behind than my team members, it just means that I have more room to improve, as long as my teammates are supportive of my growth, in spite of me not being as strong of a team member (yet). I’m sure that initially, I will have difficulty removing the feelings of intimidation of working in a more challenging group. One of the additional risks of joining this kind of group is the possibility of feeling incapable or under-performing. However, as the section explains, I would be able to recognize how much I have truly advanced in skill when self-assessing.

This section also changed my thinking regarding comparing myself to other developers. With my current mindset of impostor syndrome, it may not be best for me to compare to those who are more experienced than me. But, as my attitude towards my own skill improves, it’s not a bad thing to look up to those people as an example of what I can also achieve. By seeking out more challenging opportunities, this comparison to other developers is also necessary.

Thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Your First Language

The apprenticeship pattern “Your First Language” is a pattern that specifically focuses on people who are just starting out and only have a shallow understanding of one of two programming languages. For people in this situation who don’t feel like they have very in-depth knowledge in any particular language, the solution is simply to pick a language and become fluent in it. However, what language should you choose?

I think that this pattern pretty interesting and still somewhat relevant even to people who are comfortable in a specific language. For me, even though I feel that I’m pretty comfortable with writing in Java, I can say without a doubt that I’m still very inexperienced and will run into problems that I’ve never encountered before. According the the pattern, one of the most fundamental ways of improving your experience with a language is the solve an actual problem with it. Being able to encounter roadblocks naturally and discovering a solution to it is something that you won’t be able to effectively recreate through learning from small, self-contained examples in learning resources.

One thing that stood out to me in this pattern was what was considered the most important factor in choosing your first language. It states that you should choose a language that someone around you is an expert in. By having someone with that expertise within reach, you are able to learn at a much faster rate than if you were trying to learn it by yourself. Preferably, you would be able to work on a project with them using the language regularly, but as long as you can get feedback from them, it will still be immensely helpful. While I think that this should definitely be the major factor in your decision, I’m sure many people may not know an expert of a language that they would feel comfortable enough working with or seeking feedback from. For those people, it’s important to seek out those opportunities and expand your network, but I suppose that’s easier said than done.

Overall, I feel that for those in that situation, this pattern is something that should definitely be followed if you want to learn as quickly and effectively as you can.


From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance

Learning is something that you should never stop doing. The more you know the more you will feel the independence in you workplace. As you go through the college you learn e lot, but nothing compared to what your career needs. It is instinctive to show more than you know when you stand in front … Continue reading Confront Your Ignorance

From the blog cs-wsu – Kristi Pina&#039;s Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance|| Sam’s Ships S.S.2

Sams Ships (1)For this next installment of the Apprenticeship Series, I wanted to discuss Expose Your Ignorance. This apprenticeship pattern involves being more direct with people to have the faster route on the road to journeyman instead of protecting one’s pride to find other ways to obtain the knowledge they are seeking. When someone exposes their ignorance, they will be able to learn more quickly instead of trying to appear like they are capable.

Based on what I have learned of this pattern so far, my reaction is that it was useful seeing examples of how this happens in real life for people. To me, this was something I thought of before without putting it into a framework of sorts. I found that this was interesting because of the way they explained it saying, “One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it.” It shows how ignorance does not necessarily mean they are at fault of something, it just means they are willing to work to move past it.

Taking this as a lesson to think about, the way I work will be pretty much the same. I once almost made a task over-complicated because I wanted to find my own way to work on it instead of just asking another developer for their opinion on whether I was doing something correctly. After deciding to ask for help thought, we figured out that there was a much more simple way of going about it instead of changing a whole system of developing a certain feature. Due to this, I have gained more confidence to ask people when I am uncertain about something because in the end it would save a lot more time and avoid confusion.

I did not disagree with anything brought up in the pattern so far because I believe people should be able to communicate when they are not confident about something or at least ask for clarification. After some thinking, I realized I’ve never expected anyone to know everything so why should I feel like other people should expect the same from me?

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.