Category Archives: Capstone

The Clean Coder: Chapter 7 & 8

This week in the Clean Coder I read chapters 7 and 8. These chapters covered a lot about testing. Acceptance testing and testing strategies to be specific. One of the more interesting topics that was talked about was estimates. This is an interesting topic to me because a few months back I listened to an interesting podcast on the same exact topic. Now Uncle Bob didn’t go into as much details here as did Steve McConnell on the podcast but he made the most important point:

Professional developers understand that estimates can, and should, be made
based on low precision requirements, and recognize that those estimates are
estimates.

The later-half of that quote is the important part. The statement that estimates are estimates is important. A lot of the time estimates are taken as absolute fact in industry and unfortunately this has become poor practice. Once we remember that estimates are estimates then we start taking uncertainty back into account and everyone is happier for it.

In chapter 8 Uncle Bob began talking about testing strategies. The first point he decided to hit was actually a reiteration of something he said in an earlier chapter, “QA Should Find Nothing”. My understanding initially is that as a developer you should make sure QA has NO role. However, this is not the case. The issue here was my view on the role of the QA engineers. I assumed that their job was to catch the bugs I missed. This is wrong. According to Uncle Bob their role should consist of creating automated acceptance tests and characterizing the true  behavior of an application.

The rest of chapter 8 continues to talk about the different types or stages of automated testing. These are things like; unit testing, component testing, integration testing, system testing and exploratory testing. These are all things I’ve talked about in previous blog posts so I won’t spend too much time talking about them. I do however, want to note one thing Uncle Bob mentioned,

Unit tests provide as close to 100% coverage as is practical. Generally this
number should be somewhere in the 90s. And it should be true coverage as
opposed to false tests that execute code without asserting its behavior.

It’s interesting that when he talks about code coverage he makes it a point to say that our tests should assert something about >90% of the code we’ve written.

That’s all for this week. I look forward to the next week’s chapters which talk about Management and go into more depth about Estimations!!

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.

The Clean Coder: Chapters 5 & 6

Ahhhh Uncle Bob, You always enlighten my week in some way!

This week in the clean coders I delved into chapters 5 & 6. These chapters talked about Test Driven Development (TDD) and Practicing respectively. These chapters really didn’t introduce these topics to me as these are things I’ve known about for a while but, they shed some light on a few areas that I haven’t heard of before.

In the topic of TDD Uncle Bob made a statement about TDD I hadn’t truly thought of before – Courage. He basically stated that when you follow proper TDD practices you gain courage to go back and fix code. The reason for that is because, we will know whether or not we actually broke the code or not when trying to “fix” it. I’ve worked on a few projects now that I went the wayside of TDD for two reasons, I didn’t really understand it and it seemed like a waste of time. However, even though these were small projects mainly going to be used by myself, when I come across a bug (That wouldn’t have been there in the first place if I’d TDDed) I am always nervous to touch the function or method again. I find myself between this state of “Well did the bug really hard the ability of the software to work? Should be fine.” or “During normal use this shouldn’t happen, I can leave it be.”. Where as if I had written tests I wouldn’t be fearful at all to rewrite and “fix” old code!

Chapter 6 delved into the topic of practice. Uncle Bob seemed to mostly talk about practice in the terms of physical speed of writing code. Like, writing the same method over and over to gain speed of being able to write methods. I’m not going to lie, this is something I’ve done. I’ve worked hard creating code snippets and practicing using key-binds to be able to get the most out of my workflow. The less time I spend writing “boiler-plate” the more time I actually get to be solving the hard problems (aka the “Fun stuff”).

Practicing your workflow and making sure you can code really quickly and you are good with the tools you are using is an important thing. However, one thing I feel Uncle Bob missed is practicing our language specific knowledge. I know for myself and the projects I’ve worked on, every time I don’t have to refer back to documentation is major time saved. One thing I’m not saying is that we should spend major amounts of time learning the deep dark corners of each language. What I am saying is that you should know how to do semi basic things in the language you are working in, without referring to documentation. I remember working on a PHP project where I was doing a massive amount of string manipulation and find/replace type stuff. The first few pieces of code I wrote, I would google my problem and typically find a similar solution to what I needed on Stack Overflow. I would then go to the PHP documentation and see what it had to say to try and figure out the rest of my problem. I found that I kept coming back to the same 4 or 5 functions so I decided to commit these to memory and really try and understand the full capabilities and “hackish” things you could do with each. The 3 or so hours I took reading the documentation about string manipulation probably saved me a week or two worth of work over the projects duration. I’d say that’s worth it!

All in all another great week from The Clean Coder. I am really enjoying this book and cannot wait to see what Chapters 7 & 8 have in store! Thank you Uncle Bob for this awesome book.

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.

Capstone Project: Week 3 Reflections

Yet another week here and gone. This weeks reflections will be fairly brief due to it being the end of our sprint and having a weekend with nothing to work on. However, we did have a sprint retrospective this week due to our sprint completion! The retrospective went well. Our team has really great communication and that has helped us, so these retrospectives are just re-caps of things we found during the week.

One of the major issues we discussed was with our daily stand-ups. Due to us having to all do them remotely there leaves a lot open for loosely worded statements. We were using a lot of “I’ll try” or “I might get it done” and we wanted to clear up this language and be more precise. We found that two things happened when we became more precise.

  1. Others trusted what we said and knew we were going to get done what we said.
  2. We held ourselves personally accountable to truly get the things done that we said we were going to.

These two things I feel are very important for any scrum team!

We did our first real sprint planning today and I am very excited to start working with the AMPATH code and seeing what true professional software looks like!

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.

Capstone Project: Week 2 Reflections

Another week, here and gone. Man time flies by when you’re having fun!

This past week the group and I made our first approach to google’s javascript framework, Angular 2. We dove right in with TypeScript and Angular2 by following the Tour of Heroes tutorial. This was pretty awesome but also very overwhelming. I found that it was quite a bit of information to digest in such a small amount of time. I, just as many others, learn best by solving problems of my own so I actually tried to tweak the tour of heroes a little bit here and there to learn a little bit more. As we dive head-long into the AMPATH project I am sure there will be times where I am completely overwhelmed, due to having to learn this brand new framework but something about that really gets me giddy like a child! I enjoy stretching my knowledge base and this is a for-sure way to do that.

In retrospect, one tutorial felt too short and I felt I didn’t learn enough. Myself and others in my group have decided to append our sprint, mid sprint to extend our Angular 2 learning. I have started reading the advanced guide to Routing on the Angular website to try and glean a little better understanding in this complex topic.

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.

The Clean Coder: Chapters 3 & 4

Another week done and two more chapters of The Clean Coder read. This book has been quite enjoyable and it’s nice to have assigned reading from school that isn’t so “text-booky”. It’s nice to have something to read that is someone’s personal experience in the field of software engineering and hear about his successes and mistakes.

Chapter 3 talked about the flip side of chapter 3, saying yes and when to say it. I really enjoyed this chapter because it’s something I had make an conscious effort to approach in the past 9 months or so. I noticed at work I was using the phrases “try to get it done” and “might get it done”. I noticed this was simply giving me an excuse to take things at more of a relaxed pace and maybe not giving 100% to my employer. In May or June (I do not recall the exact date) I was moved into more of an IT infrastructural role at work. My first task.. Fully rebuild the LAN/WLAN structure of the facility. The president of the company told me this was of high importance to get this done a.s.a.p. and requested I estimate how long this would take. After some research and getting the things I needed on order I gave my boss a definitive date of 2 weeks until completion. Because I gave the president a definitive date and completed 2 days ahead of that date. He then started giving me tasks that we meant for my immediate supervisors because he knew that we would get a date things would be done by. I have since found that using correct language and giving good time tables creates better channels of communication and makes everyone in the organization happier.

Chapter 4 was the first time I had some serious differences in my ideas compared to Uncle Bob’s ideas. This was negated by the fact that he explicitly stated:

You will likely not agree with everything I say here. After all, this is deeply personal
stuff. In fact, you may violently disagree with some of my attitudes and principles.
That’s OK—they are not intended to be absolute truths for anyone other than me.

I find it funny that he had to mention 3 AM code. It seems to me that the general idea behind anyone who has tried solving a difficult problem with programming has come across this at least once in their efforts. I know I’ve talked with multiple programmers who all say the same thing, “If you can’t solve it, walk away for a while”. I’ve even told this to many programmers. It’s just a fact of life with any issue you can’t solve immediately. If you walk away and let your subconscious mull on the issue, 9 times out of 10, you’ll find the solution.

The one major thing I disagree with Uncle Bob on, is listening to music when trying to be productive. I am never more productive without music. I imagine this is something that changes from person to person as well. I know for my wife, she’s the most productive when things are dead silent. Now she’s a not a programmer and has never written a line of code but everyone has their own way of steadying their brain to focus in on a task. Part of my ritual to steady my brain is put on some music. Now I know that he also mentions avoid getting into the zone and this is something I already avoided anyways. But what music helps me accomplish is two things. It helps me set a rhythm to my work that keeps easily distracted part of my brain busy. Also, when I have headphones in it lets others know that I am baring down to get work done. In my office there are times I simply need to get stuff done and don’t have time for idle chit-chat. These are the times I find music especially helpful. If someone needs me they know they can simply come in to my area and I will almost always take my headphones off immediately. However, it puts up some sort of barrier that tells people I am too busy to chat about non-work-related topics.

All-in-all, it was another good week of reading what Uncle Bob had to say on Software engineering! I look forward to see what he has to say in Chapters 5 & 6.

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.

Capstone Project: Week 1 Reflections

This was the first week we began working on the Capstone project class. This week we didn’t do too much in the line of actual development so I don’t have too much to talk about. However, we did form the teams that we’d be working with for the entire semester. Myself and a group of my friends were lucky enough to all be paired together. We’ve done some group projects before and know each other’s work ethic and what we need to do to push each other. I really enjoy working with these teammates as well, so that helps immensely when you’re about to spend the next 3 months with them working on a project.

We are going to be working in the Ampath project that is part of the OpenMRS group project. I have looked into the OpenMRS project prior to this class but never took the dive to begin developing for them. I am incredibly excited to have an opportunity to work with a code base as large as this one. This will be the first time I really dive into a project that I haven’t worked on or seen previously and will be working with someone else’s code quite a bit and that will be a new experience as well. The project we will be working in using Angular2 which is a javascript framework that I have done small personal projects in but haven’t done anything to this scale so I am incredibly excited to be getting this experience as well.

As a side note apart from school, I have been brushing up on my Angular2 skills by following this scotch.io tutorial as well as learning Ruby during some of my extra free time. I am enjoying Ruby as a language however, I find developing in PHP to be my comfort zone and ruby syntactically is a bit different. I find myself forgetting to close if statements with end as well as my loops. I am sure this is something I will get used to but it will take time!

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.