Hey everyone! Back for my final semester which means more blogs. By more blogs I mean two a week this time! I will be constantly writing about my experience in my SCRUM team along with my learnings, but also I will be noting information from our book The Clean Coder. I can’t wait to see where this goes, hope you all enjoy!
From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.
Welcome back to my mediocre last minute blogs!
I will be doing a couple things with these blogs moving forward.
I hope to make these easy to follow, and add more flare than my last blogs had …..
From the blog CSWSU – Triforce Code| Exploring and Learning by CSWSU – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.
Professionalism:
The term professionalism is the defining factor of responsibility and accountability in the real world. One must own up to their mistakes (potentially being letting a bug slip through). The first rule of professionalism regarding software developers is to not harm the function nor structure of the software being developed. There is no perfect world without mistakes, but as previously stated; own up to them, learn, react accordingly. You should know and trust that the code you release will have nothing left for QA’s to find. This is an industry of continuous learning meaning that out of work practice and reading will be required to stay up to date.
Saying No:
This chapter has a long disaster story about what can happen from premature deployment of software. Afterwards speaking about how managers and developers have roles that are adversarial, or opposing, because their goals tend to conflict on the short terms. The manager wants to release the code to make the deadline, but the code is not ready and you are aware. The higher the stakes of the deadline, the more valuable a no becomes on your end.
From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.
Week 1:
The introductory week consisted of the set up for the rest of the semester; mainly being building our teams. We built our SCRUM team: ZOLINQ. The sprints will begin shortly but for now we are seeking information on our project which entails coding new features for the AMPATH section of OpenMRS. My team is actively communicating on slack to share information about these organizations.
From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.
I read the the introduction, chapter 1 and chapter 2 of the The Clean Coder by Robert C. Martin. I found the introduction funny because the author basically quit the job he did not like while he was making $7,200 a year and and a few months later got the same job back for $6,800 ! I guess the lesson to learn here is the importance of wisdom.
The second and third chapters were about professionalism and when to say no to something (how to be a professional). Being a professional means that you care about the product you build and take responsibility for any problems that may arise. The author explains that to be a professional you must not create bugs in your software and if you make an error, you must apologize. Never release any code that you know to be faulty. And the software you write must be flexible.
The author also talks about the importance of learning. It our responsibility as professionals to make sure we are marketable. We have constantly to learn and strive to improve ourselves.
I found the second chapter interesting. The author explains why it is important to say no to a request by your boss and why not to use the word try. I think following this idea is hard in practice. What if you boss insist you complete something within a certain time limit (which is not possible)? It is very easy to just comply, but it is hard to say no given the fact that your boss has the authority to fire you. But I guess being a professional is not easy, you have to put the software that you produce over everything else.
From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.
Hi everybody,
My name is Haider Hussain. This is my introductory blog for CS448 Software Development Capstone. I’m a little late, but excited to start this new blog for this new course. I’ll be posting my entire learning in this courses here.
From the blog CS448 Software Development Capstone – Computer Science World by Haider Hussain and used with permission of the author. All other rights reserved by the author.
Hey everyone,
This is basically just a post saying hi and testing to make sure it links to the CS@Worcester blog. I am super excited for this Capstone class and to be working with the OpenMRS group. Excited for the semester ahead!
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.
I read the first 2 chapters of this book almost 16 months ago and I did not quite understand the significance of clean code back then. This week I decided to listen to the video version of clean code (available in SafariBooksOnline). The video version made it much easier to understand and I had a few good laughs.
In the first chapter Uncle Bob explains why clean code is important. He tells us the story of Sword Inc, a software company that failed because they produced bad code. When code is not clean the productivity of the development team decreases as time increases. The reason for this loss of productivity is that the developers build a mess as they develop the product. And the software product eventually fails becuase when the management demands new features within a certain deadline, the development team is not able to deliver because they just can’t.
The management tries all sorts of things (like increasing developers) to improve productivity, but nothing works. According to Brook’s law, adding more man power to a late project makes it later.
Finally the management turns to the developers for a solution. The developers solution is to redisgn the entire system! Management does not want to do this since it is expensive. The mangement however, after some time, decides to do it. But even this would not solve the problem. Eventually the company would loose customers because when they replace the new product for the old (more feature rich) product, customers leave for better products.
The only way to solve this problem is to stop running away from it and clean the mess.
So what is bad code? You know that a software systems contains bad code if it is rigid, is fragile, lacks seperability and is opaque. Uncle Bob goes on to explain that bad code is the fault of developers not management, not anybody else.
The second chapter is all about making your code more readable with the help of better naming strategies.
I can relate to this chapter and the Sword Inc company failure. Last semester I wrote software for a class project. Since we only had a limited amount of time and a bunch of requirements to fulfill, I rushed through the development process. As a result of my rushing, the code lacks the properties of clean code. If I had to use the code again or implement a new requirement, I would be lost.
From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.
Hello world, again. If you are not familiar with my blog posts that were posted between the past couple of months, that’s ok. I took a break and I am back to using this blog, however this time I will not be talking about software testing. As part of my final Computer Science course, I am working on my capstone which entitles a software development project where I am with a group of 6 working on features for an initiative called OpenMRS. OpenMRS is a open source medical record software which is currently powerful and expansive with a lot to offer to the world. This blog will be used to document my progress on this project as well as the readings that have been assigned for me to do as well. The aim is two blog posts a week, unlike one blog post a week like last time.
For more on OpenMRS, you can view it their site here: http://openmrs.org/
From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.
Hello this is Kyle Ott and this is my introductory post for Software Development Capstone course.
From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.