Concrete Skills

This week I read the book Apprenticeship Patters guidance for the Aspiring Software Craftsman. There was this one section that caught my attention and it was the Concrete Skills. This was very interesting to me because it’s quote was “Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. this is where craftsmanship comes in.” Growing up we are taught that you need all the knowledge you can to even be able to be considered for a job. Many people tell us that you need even a masters to be considered for a job these days anymore. However there was a professor I meet back when I first started  programming he told me he used to be the hiring manager for IBM and he meet hundred of different candidates that tried and applied for the job. The things he learned about hiring people is that not everyone is the same.  Yes there will be people who have the knowledge of programming and would pass all these tests and get everything right. However,  once it came to actual coding and work ethics they were very questionable. There are people who got out of college that have a different perspective. They say that  everything you learn in school isn’t going to be helpful in the real world. Most of the time you learn all your skills once you get a job where they teach you what skills you need. It is really all about if the job would take the risk and hire you. There are many stories that there are people who have basic knowledge of programming are hired because they have experience in other fields that can be used to help out the team in different ways because you don’t just want a team of programmers that know one language but a team that can cover each others weaknesses. That’s why I think that this sections is very good because it gives a real perspective of what companies should look for in a person not what they can do now but how will hiring them affect us in the future and the capability of these people in the future.

Advertisements

Software Complexity

Source: http://www.castsoftware.com/blog/five-reasons-to-measure-software-complexity

This week I looked up Software Complexity blogs. I found a blog called “Five Reasons You MUST Measure Software Complexity” written by Jonathan Bloom. This blog talks about how sometimes complex code aren’t the best thing. He gives you a few methods developed for measuring software complexity. Which are Cycomatic Complexity, Halsted Volume, and Maintainability index. With these methods companies and use the information found by them to capitalize how they are writing the code such as. Greater predictability because knowing the level of complexity of the code can make it easier to maintain and show how much maintenance a program will need. The software risk mitigation which manages the software complexity lowers the risk of introducing defects into production. Reducing cost because with lower mateine cost the origination can spend that money on other things. It extends the value of the programs because excessive complex application causes issues. With this it keeps the software in cheack and keeping the complexity of it in check. Finally, decision support with this it allows the owner the information to tell if it is worth the cost of even fixing the code or if writing new code be worth it.

The benefits of software complexity analysis are that it improves code quality, reduce maintenance cost, heighten productivity, increase robustness, and meet architecture standards. Because of this a lot of bigger and smaller business try to add this analysis to make sure that they are not losing money because the software is too complex for what they need. I like this blog because it backs up one of my other blogs that talked about keeping code short and sweet. We should do code as basic as we can to keep things neat and organized and don’t make it crazy so that way we don’t waste time doing things we didn’t have to do. I think I will keep this in mind when I move on to my next step of my life. Keeping code nice and simple is the best way. I also think that I will keep this in mind when I am working on the final project for many of my classes because we don’t want to write too complex programs for our robotics class and our software constr class as well

 

C4 Diagrams

Source: http://codermike.com/starting-c4

This week I decided to look up C4 Models and I found a blog that talked about what C4. This blog post called “getting started with C4” by Mike Minutillo talks about what the C4 model is. The C4 model is a way to let users communicate and describe software architecture. This is really good because when working in a group and asked to draw out the architecture of your code besides having everyone draw up a different drawing than each other everyone would have the same kind of structure across the board. C4 models is a toolbox that allows the team various well-defined layers of abstraction to develop and communicate the static structure of a solution. He then goes and talks about what the toolbox is and abstractly it is a software system that is made up of one or more containers, each of those contain one or more component which in turn implements one or more classes. With C4 there are 4 different levels of abstractions. Context, Container, Component, and Class (which is why I guess it’s called the C4. Makes sense, right?) Context shows key systems, the dependencies between them and the actors that access them. Container shows the high-level technology choices, how systems are decomposed into containers and how those containers communicate. Component shows the internal structure of a container and how it is decomposed into collaborating components. And finally class is a typical UML class diagram showing the internal structure of a component.

Why I like this blog is that in the blog Mike tells the readers step by step how these C4 diagrams are made and the perks of using it. They are very similar to UML diagrams so that way when showing these to the customer it would be easy for them to understand what you are writing and also I like this a little bit more because I feel like with the C4 diagrams they are more meant for programmers to share with each other and if someone were to join the project later on they would look at the C4 diagram and would not be lost on what to do. I think it is great that we have many ways to show our work besides UML diagrams and we are not stuck into one way of showing things and I would be using these types of diagrams in the future. This would be useful for future project in class and even when I move onto bigger and better things.