Category Archives: week4

YAGNI

Welcome back!

This week in Coding Kitchen, we explore one of the key principles of Extreme Programming, YAGNI (You Ain’t Gonna Need It). This principle states that some capability we think our software will need in the future should not be built now because “you aren’t gonna need it“, or as XP co-founder Ron Jeffries put it, “Always implement things when you actually need them, never when you just foresee that you need them.”

The YAGNI principle is to be used in conjunction with other practices, such as continuous integration, continuous refactoring and continuous automated unit testing. Without the additional use of any of these other practices, your code could go into Technical Debt, which means it could become disorganized and need to be reworked. Using the YAGNI principle saves you time by helping you to avoid writing code that you do not end up needing and by making your code better because you did not have to fill it with guesses that turned out to be wrong.

In an article posted by Martin Fowler, he uses an example about selling insurance for the shipping business. His example states that an insurance company’s software system is broken into two components, pricing and sales and that the dependencies cannot usefully build sales software until the relevant pricing software is completed. His example also states that while the company works on updating the pricing component to add support for risks from storms, they consider working on a feature they will not need for another six months for piracy pricing. By adding on this additional feature now, Fowler declares that doing so would incur three classes of presumptive features, and four kinds of costs that occur by neglecting YAGNI for them.

1) Wrong feature — Cost of building, cost of carry + cost of delay
2) Right feature, built wrong — Cost of repair, cost of carry + cost of delay
3) Right feature, built right — Cost of carry + cost of delay

I chose this article because this particular example given by Fowler highlights the benefits of using YAGNI and why neglecting to do so would inherently cause many issues and become costly. As a future software engineer, I would prefer having to write less code that is easier to understand rather than have lines of useless, possibly obsolete code. I found Fowlers explanation of YAGNI and his further explanation of the many ways applying this principle could cause problems in comparison to the very few ways it could be of benefit easy to understand and useful. Having knowledge of this principle as a programmer will make writing and editing code in my future professional endeavors much more time and cost effective.

Inspiration and information gathered for this blog post :

https://dzone.com/articles/martin-fowlerbliki-yagni-youre-not-gonna-need-it

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

THE DEEP END

What is life without risks? Standing still without challenges, or without the will to change a small part of your life is not living your life to the fullest, and that is exactly what I feel. Reading this part of the book made me realize how it’s hard for me to change small things about … Continue reading THE DEEP END →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Concrete Skills

Hello and welcome back to benderson’s blog! This week we are discussing another pattern in the Apprenticeship Pattern book called “Concrete Skills”. Concrete skills discusses the problem of wanting to join a team that will lead you to a big learning experience but they probably won’t let you join do to you not having the credentials to work on the project therefore being a rock in a bag that they got to carry across the finish line, in other words you would be holding them back instead of helping them move forward with the project. The book provides the solution of maintain your concrete skills as it may influence them to trust you and let you on the project. Some of examples of concrete skills they provided were; writing build files in various popular languages, knowledge of open source frameworks and standard libraries. This still may not get you hired to the job as managers would have to take a leap of faith on you but having these skills will make that leap of faith a little bit closer. The book also suggests collecting the CVs of the people you respect as you can learn from their CVs and pick out certain things that they do well with and learn from it, this will allow you to create something to show that you have learned and may get you on the team.

The pattern “Concrete Skills” is intriguing as it is how every job usually works that has high end problems with it and needs the best workers on it. The most knowledgeable will always be working on those projects as the people who need the experience and want to learn will have to sit out on it as they can’t hold the team back from completing the project on time. Now the goal of the person that has to sit out of the high-end projects has to become the most knowledgeable to be able to work on the next high end project or join this one. This pattern talks about the ways you can do that and it’s through learning from outside sources, online research or even your colleagues are a couple of outlets you can use to become the one of the most knowledgeable in your workforce. Acquiring a CV from one of the people working on the high-end project would be a great way learn and be like that person which will greatly increase your chances of being hired for the job. Concrete skills is exactly what you need for the baseline but you need to rise to the occasion to improve those skills and become one of the best.

From the blog CS@Worcester – Benderson's Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.

Post #3: What/Why Software Testing is Important?

Hello and welcome back to Benderson’s blog where we discuss computer science topics that are happening in present time. This week we are going to discuss what is software testing and why it is important, I got this topic from a blog post posted by Harshit Satyaseel at Technotification. He talks about everything to do with software testing which is very helpful for people to understand and get what is software testing. He first starts by talking about what is software testing and he defines testings as “confirming that whether the actual results match the expect results”. Testing is a long process that makes sure that each and every software component/system passed the expected standard of performance set. Testing in software can be done manually or using automated tools. He then goes into why it is important to test your software and lists off reasons like finding defects/errors in the code, the quality of the software, and some more important reasons. Then he goes into software testability and lists off some characteristics of testability. Generally, what testibility is, is the guidelines and rules of testing and what you should look for to fix and make an improvement on.

The reason I choose this blog to write about besides the fact that the course I’m taking is focused around software/code testing is because it had some interesting tidbits and good guidelines to look for when testing mine or someone else’s code. The writer also talked about what software is which most blogs really don’t do when they are talking about something inside computer science, they always assume you know exactly they are talking about regarding the topic. For me, I know what software is but for the common person trying to gain knowledge on software being told what software is and why software testing is important makes the reader more knowledgable on the topic. He even gives the fact about Alan Turing in 1935 with the theory of software which was a nice touch. When he talks about the reasons for testing software, I like how he listed them out instead of creating a huge paragraph that is a jumbled mess about it. They are also very well listed and easy to understand regarding to software development. I will keep the guidelines and rules that the writer talks about in my mind whenever I test my code now, they are very good things to keep in mind. Thank you for joining me this week and reading my blog post.

Link: https://wordpress.com/read/blogs/74482552/posts/18309

From the blog CS@Worcester – Benderson's Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.

Use Your Title : Pattern 2

In this pattern, the author presents the issue of people getting moved into different roles due to their dedication to mastering their crafts and art.  usually when you become outstanding and put in time to better and help you team improve you begin to create a chain reaction of quality standards that either get matched by your peers who in turn become better programmers or you are put in a position to defend your processes and methods. ON the management level , this will serve as a sign that moves you to a leadership role or position in the company. It is at this point that the author wants us to understand that we do not need to conform to the pressure around us. As a software craftsman, you are to remain that and continually improve your craft without breaking into the distractions around you. we are not to allow ourselves to be controlled or changed by our title but we are to leave it at the outskirts of our consciousness. Once in such a position, do not be swayed by the positions descriptions and demands but instead use that as a gauge to assess your organization. If you were noticed due to you outstanding qualities, hard work and knowledge, it should serve as a sign for you to evaluate how well the organization seeks for growth and progress. On the other hand if you are not recognized although you are still exerting these qualities, that should also paint a picture of where the organization is headed. Everyone wants to be recognized when they do things that are deemed to be recognized so an organization that fails to recognize this often lose out on the talents of such a person. whiles companies that pay notice to things like that keep acquiring people of such traits. Another possible scenario that often results from this trend is the differentiation of both informal versus formal titles.Many times employees begin to grown into a positions of authority on teams, despite their formal title remaining the same. Growth into positions of authority booms with familiarity with the job, development of skills and an overall understanding of the specific companies processes and task. The more you understand, the more you can explain and the more you are familiar with a process, the better you understanding of it. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.