Should I learn how to code or learn another language?

Posted on 3 December 2017 by Wayne Cook

I have been working with software development since I was a junior in high school. I have used at least twenty-five languages for various projects. I can take my coding skills from language to language (at least in groups of languages). What type of development would you like to do? The answer to that question will determine what practices you need to develop for your coding skills. Once you know that, then it is wise to choose a language that will help you develop those skills. Learning how to code goes hand-in-hand with learning a particular language. Unless you want to do legacy programming (FORTRAN, Assembler/Assembly, or COBOL), I would suggest learning structure programming/coding language like C, Algol, Ada, or Pascal. C seems to be the most common language in this group. These languages would be good for learning basic coding skills. For more advanced skills, I would recommend an Object Oriented language. The language with which I started was SmallTalk, which is not that commonly used anymore. Other languages include C++ for a compiled-to-a-specific-architecture language, Java for a language that compiles  to run on a virtual machine, or Python if you want to learn an interpreted language. Java would be good for you to learn coding for mobile phones. If you are doing work on Microsoft platforms, then C# would be the language to use.

If your interests are in web development, then I would recommend a combination of html5, CSS, JavaScript, and PHP (and possibly Python).

Almost a totally different mindset is needed if you plan to do string manipulation and searches. Some of the languages listed above would do well, but there are languages specifically designed for this. Two that I have used are Snobol and Prolog. Prolog (SWI-Prolog) is a much more modern language than Snobol (SNOBOL4 Resources), but both have their place.

As a side note, the language with which I had the most fun was LISP, it has since evolved into Common LISP (Welcome to Common-Lisp.net!). It is just as old of language as FORTRAN and COBOL. but totally different. In fact, it will warp your coding techniques and think in ways that you may never have thought before.

Bottom line, learning good coding techniques and learning a specific language go hand-in-hand. Some basic coding techniques are true no matter what language you are using and will serve you well in all languages. Other coding techniques have developed around a group of languages, like Object Oriented Programming. Good luck in whatever you choose to do.

Posted in Code Reviews, Computers, Software | Tagged , , , , , , , | Comments Off on Should I learn how to code or learn another language?

Do You Really Want to Work for a Large Corporation?

Posted on 24 September 2017 by Wayne Cook

Hewlett-Packard and Tektronix, two companies for whom I have worked, were once garage-shop companies. Most companies start up that way and grow bigger as they reach their goals. The founders of companies care about their companies and the employees, the people who take over leadership after them do not care nearly as much. Under the founders of HP and TEK, there were no lay-offs. In tough times, they found alternate solutions to keep people they hired employed. Howard, Bill, and Dave all felt that if you cared enough to help their company succeed that they would return the favor and care for you when times got tough. This speaks highly of the environment in smaller companies that are growing. The smaller companies with whom I am familiar, also have far less overhead in terms of paperwork and meetings and far more emphasis on getting the work done. If you are familiar with the Scrum Methodology (Scrum Methodology), the philosophy of a good smaller company fits more closely with rapid quality software development. I am not saying that larger companies cannot also develop quality software, it just requires more hurdle jumping. As a side-note, look up Skunk Works for an example of a big company doing just this.

Back to your original question, doing something you love is far more important than working for a large corporation. When choosing a company, choose wisely. Look for a company with either good financing or a great idea than you feel you can substantially contribute to it being successful.

Big companies do not provide the stability they once did (Hewlett Packard Enterprise Is Said to Plan About 5,000 Job Cuts). I was project-lead at Hewlett-Packard when I was asked to put together training for the product development to be shipped to India. A bit later I was a part of the HP Work Force Reduction and given six weeks to find work within the company. At the same time, the CEO put a seven week moratorium on internal hires.

The bottom line is to choose what you want to do, look for a good company who is doing that, and then hone your skills in that area and show the company how you can help them with their success. Good luck.

Posted in Agile Methodology, Attitude, Becoming, Computers, Divergent Thinking, Do, Financial Health, Fulfilling Life, Goals, Mentor, older Americans, Planning, SCRUM, SCRUM Methodology, Self-Worth, Software, Thinking, Uncategorized | Tagged , , , , , , , , , , , , , , , | 1 Comment

And Grace will Lead Me Home

Posted on 2 September 2017 by Wayne Cook

“Through many dangers, toils, and snares
I have already come;
‘Tis Grace that brought me safe so far,
And Grace will lead me home.”

I am celebrating a major anniversary of my time here on earth this month and it has led to much contemplation. Hearing one of my favorite The Piano Guys songs has added to that contemplation. I have had many good friends and a few very close friends over the years. I wonder how each of you are doing. It is hard to believe the amount of time since I was in California, Denmark, Oregon, Guam, Indiana, Pennsylvania, and Texas. There are some very special memories I have of each place, but most of them revolve around individuals who were a part of my life. This year I am celebrating 40 years since I graduated from Indiana University. It only took me one year to earn my Masters of Science in Computer Science. That degree allows me to teach at Colorado Early Colleges, jointly with AIMS Community College. It has been a grueling, but enjoyable three weeks. It is good to continue to learn and have the opportunity to share with others. There is so much about which I am thinking (and thankful) at this time and I will be adding to this as the month progresses. I wish each of my friends the very best, whether we are in touch or not. May you be blessed in all that you do.

Posted in Uncategorized | Comments Off on And Grace will Lead Me Home

Gemba – Designing for the Person – Scrum

Posted on 19 July 2017 by Wayne Cook

Gemba is an interesting process for management introduced by the Japanese. In Japanese, it is often pronounced “Genda” and written 現場. Gemba means “the real place.” Its goal is to see how work is done and tools are used, then designing the tools and work area and process to make it easier to accomplish the task at hand. This is a great concept to help developers using the Scrum/Agile Methodology to develop better designs and implementations. The best example of the use of Gemba is in its use in the medical field presented by Deborah Adler on TEDxRVA.

For Deborah’s work, designing for the individual to solve a specific problem is the key to a great design to solve a common problem for many individuals. Her key phrase is “Don’t create for the world, create for a person.”

Observation, listening, and correctly perceived problem identification is the key to Gemba. This fits very closely to the purpose of Scrum Methodology and specifically two-week Scrum Sprints. Each Sprint needs to have a deliverable. All Shareholders are involved with the initial Working Agreement and the final acceptance of what is produced (or “Done“) in each Sprint. Use these opportunities to create the best product possible. Gemba was developed independently from Scrum, but there are many similarities. Both emphasize streamlining the process as much as possible. Make the product as simple and intuitive to use as possible and remove any unused overhead that hinders the progress of either the developers or users of the product. Gemba is a tool for leaders, managers, and supervisors. A Scrum Master is the facilitator of the Scrum process, and is the leader or go-to person all the members of the team consult on ways to produce a better product more quickly. Scrum Masters would be benefited from understanding Gemba.

A good example of how to implement Gemba was given by Steve Jobs when asked about the detail of the use of Java and the purpose of OpenDocs at Apple. As CEO, Steve Jobs could not know the detail of every project, but must be aware of and set the overall strategy, vision, and mission for Apple. When confronted, he acknowledged that there were valid points to the gentleman’s criticism. Then he adds: “The hardest thing is: How does that fit into a cohesive, larger vision, that’s going to allow you to sell eight billion dollars, 10 billion dollars of product a year? And one of the things I’ve always found is that you’ve got to start with the customer experience and work backwards to the technology. You can’t start with the technology and try to figure out where you’re going to try to sell it.” The whole point of Gemba is to know the customer and the customer needs. How do you solve those needs than not only meets the needs but thrills the customer?

Posted in Agile Methodology, Attitude, Computers, Gemba, Health and Wellness, Medications, Planning, SCRUM, SCRUM Methodology, Uncategorized | Tagged , , , , , , , , , , | Comments Off on Gemba – Designing for the Person – Scrum

Do Until You Become

Posted on 15 July 2017 by Wayne Cook

I went to a meeting of TEC-P (Technology Employment in Colorado Partnership) in Denver on Thursday. It was a fascinating meeting that started off with a TED talk on Body Language by Amy Cuddy.

We have viewed Body Language as a way to determine how other people are feeling, but Amy points out that it can be a great influence on how we feel about ourselves. Our body posture and language tells our minds whether we are powerful and in control by being large or submissive and subservient by being small. A classic example of a power position is the Wonder Woman pose. When we are interviewing, we are advised to loosely mirror the interviewer’s posture and enthusiasm. However, it has been shown that too often when the person with whom we are talking takes a power position, we instinctively assume the submissive (small) position. If you watch the embedded video of Amy Cuddy, you will see several examples of this.

In this video, Amy repeats a common phrase that is used quite often, “Fake it until you make it.” She modifies it to “Fake it until you become it.” I would like to make one more modification to this phrase to be “Do it until you become it.” Amy gives an excellent example toward the end of the video about overcoming the effects of a serious car accident where her brain injuries left her with a two standard deviation drop in her IQ. Since she had always been labeled as gifted, this was a devastating setback to her. Amy Cuddy heard from multiple people that she would never finish college. She struggled through undergraduate school, but eventually was accepted to graduate school. She was blessed with an excellent counselor/mentor who made her “fake it” until she believed that she had become the good student she always wanted to be.

We are often called human beings, but I think that we need to change this to state that “We Are Each a Human Becoming.” There is an old saying in business that “If your company is not growing, it is dying.” This applies to each of us as individuals also. When I want to do my best, I ask myself each morning “What will I learn and do today?” The bookend to this is to write down at night a brief summary of What I Have Learned Today. When we are at our best, we are geared to continually learn and do what we learn to become our best selves. Life is too short and we should expect nothing less from ourselves.

Darren Hardy of Success Magazine said on one of his Daily Mentoring videos that we “need to eat the frog first.” I have the most energy in the morning, as most people do. Eating the frog first means to figure out what are the most important tasks that we need to do today and understand the reason Why those tasks are the most important. Then plan out our day and do the most difficult task first. As we do this, we will gain more confidence in ourselves and we will present a more positive and powerful countenance in our daily lives and interactions with other people.

We each go through tough times in our lives. There can be many causes for these times. What we do during the hard times says volumes about who we are and how we overcome difficulty. Starting every day with some basic exercises, including practicing power postures, is a good way to have your body and mind performing at peak efficiency. For me, I really like the “Wonder Woman” pose. Also, be sure to read something uplifting. For example, read something by your favorite motivational speaker or a section of your favorite Scriptures. I enjoy doing the latter as well as listening to a Daily Motivation by Darren Hardy.

Organize and Build Your Confidence

Amy Cuddy paractices Wonder Woman pose

Superman Power Pose

Practice power positions, especially before going into a stressful situation. Power Positions increase your confidence and decrease you stress levels. Super heroes can be a good role model, if chosen wisely. Look at Amy Cuddy imitating Wonder Woman. Then compare her pose to Superman’s power pose. This can work for each of us also. Be honest with yourself, how do you feel after holding this position for 5 minutes. The video above refers to an experiment done with half the candidates taking a power position and half not. There was a very strong corrolation between those who took the power pose and those who did well on the interview.

 

Conclusion

We each need to grow daily. Start the day off with confidence. Organize the week before it starts. Organize the day the night before. Improve each day by learning something new and doing it. Practice each day on something that is important until the desired mastery level is reached. Then we need to evaluate what we are doing and modify our tasks where needed to prioritize what we need to do to become closer to the person we want to be. Always remember to “Do until you Become.”

Posted in Attitude, Becoming, Body Language, Direct Sales, Do, Fulfilling Life, Goals, Health and Wellness, Mentor, Network Marketing, Northern Colorado, Planning, Self-Worth, Serving, Thinking, Uncategorized | Tagged , , , , , , , , , , , , , , , , , | 2 Comments

S.T.E.M. is now becoming S.T.E.A.M.

Posted on 29 June 2017 by Wayne Cook

S.T.E.M. was originally designed to help young women understand and enter the technical fields. S.T.E.M. stands for Science-Technology-Engineering-Mathematics. It has been very successful by most measures.  In fact, there are various lists of essential reading for women in S.T.E.M. However, there are many people (including myself) who believe there are two missing elements to S.T.E.M. Most of my friends who are successful in the technical fields say that the Arts (Music, painting, photography, etc.) play an important piece to their understanding of the beauty of elegant technical designs. S.T.E.A.M. is becoming the more accepted term used through adding Art to the technical areas listed. The United States has led the world in technical development for several generations, but we are slowly losing that status for various reasons. The program’s aim was to produce more female graduates in the technical fields. This is great, but in my own humble opinion this is leaving out half of our population. Young men need to excel in the technical fields just as much as young women need to succeed. I believe that in adding Art to the technical education and making sure all youth have an equal opportunity to excel will give our youth and our country a brighter future.

Please study the many reasons it is important to transform STEM to STEAM. Also, the education system needs passionate teachers, not just teachers who can recite the facts. To succeed in Science-Technology-Engineering-Art-Mathematics, the students need to understand the “Why” behind the “What” and “How”, not just the “boring” facts. The best teachers are the ones who have developed a passion for these fields and can share that passion with their students. Older workers have worked with technology for many decades and have learned to adapt to the many changes in these fields. Unfortunately, many companies believe that younger workers can adapt to new technologies more quickly (and are much cheaper to hire). This is a false economy, but leaves many very capable people available to help the next generation adapt to the rapidly changing future. Simon Sinek  gave an excellent TED talk on “How great leaders inspire action” that shows the importance of passion and understanding the why behind any decision or cause.

Dreams and Plans

Anyone can understand the What and How portion of development. In fact, there are so many ways to accomplish tasks that being too concerned about the How to do something may mask your understanding of Why you want to complete that task or project. The How and the accompanying tools will logically flow from the Why you want to accomplish a particular goal. This is one reason why Agile Development (Scrum Methodology) has been so successful. It forces people to think about Why they want to achieve a particular goal. The How to do particular tasks logically fall out of understanding the Why the project is important and how a particular task fits into the entire design.

An excellent example the importance of Why over How or What is Martin Luther King and the Civil Rights Movement. Martin Luther King had a “Dream” while many of the other Civil Rights leaders had their plans. Plans are great and are eventually always necessary, but it was Martin Luther King’s “I Have a Dream” speech that inspired a generation to support the Civil Rights movement.

Learning technology is not hard, there will be challenging projects and difficult assignments. However, most people can learn any concept and technology. Teaching the facts and concepts of Science-Technology-Engineering-Art-Mathematics can succeed as long as the students truly understand the Why behind the use of the technologies and the Why behind what they are trying to create. Get all youth involved and use all the resources available to teach the technology and the passion behind the use of the technology to provide a better world for all of us who live here on Earth.

Posted in Agile Methodology, Attitude, Computers, Fulfilling Life, Goals, Health and Wellness, SCRUM, SCRUM Methodology | Tagged , , , , , , , , , , , , , , , , , , | 2 Comments

The Kindness Diaries

Posted on 3 April 2017 by Wayne Cook

Dustin Clutterbuck, a massage graduate from IBMC College, has been communicating with Steven Steele, the CEO of IBMC College to bring Leon Logothetis of the Kindness Diaries to the College to present a talk on his experience with the kindness of others.  Leon is a very kind and thoughtful person. He treated each person he met with love and respect. I was especially grateful for how he treated my son, Matthew. I will have Matthew write more about the presentation. For now, I am uploading photos to share with people who were there.

Matthew’s Thoughts

Getting to meet and speak to Leon was amazing.

Getting to hear the stories, hearing just how much the world can change with kindness and that kindness is really out there, not like the cynics say, but real honest goodness that is there because folks want it.

Folks need that connection, where a heart touches a heart, where a person is seen, feels like yes, I am a human being and I am here, and you see me.

IT was a powerful meeting, and I am humbled and honored I was able to be in the audience to listen. To hear his words and experiences and realizing I wish to commit to being a better person.

1 / 31

The Kindness Diaries Cover


Slide 1 of 31
 
  • The face behind the scenes who helps everything go.
  • The author and me
  • Had to include this one just for the look of joy.
Posted in Attitude, Kindness Diaries, Uncategorized | Tagged , | Comments Off on The Kindness Diaries

Are all Experienced Engineers Rude and New Engineers Obnoxious

Posted on 27 March 2017 by Wayne Cook

This was written in response on Quora asking if all experienced engineers rude. In many respects, it is written as a letter to new engineers just coming out of school.

I have been producing software for many years. Most new and experienced programmers get along fine and learn from each other. There are different reasons why either group is rude to the other. I will group newbies into two groups, those who think they know it all and those who realize they do not. The experienced engineers can be broken into two groups also, the hoarders and the sharers.

For experienced engineers the hoarders are rude to everyone, they either hide as much information from others (who are either colleagues or below them in the hierarchy) as possible or give misinformation. They have put themselves into positions where their knowledge is critical to the organization’s success. In the short term, they can be very successful, but when technologies change they can find themselves in some difficulties. The sharers are the best people for newbies to get to know. The ones I know keep up with technology and freely share what they know until someone does something that may not seem totally ethical. Smart managers try to keep as many sharers as possible around, especially to train the new members of the team.

For newbies, I have had to deal with both the know-it-alls and the learners. The two toughest groups I had to deal with are the know-it-alls who really did not have the needed skills to do their job and the learners who were not able to learn what their job was and how to best do it. The know-it-alls who really did know their software development were obnoxious at first, and I was probably a bit rude to them. However, to be a true know-it-all they had to have a love for learning and would eventually know that other people can help them become better at their software development skills. These people, as long as they become sharers, usually became vital members of the team. The learners who had the fundamentals down, usually learned quickly and were willing to share their knowledge with others. These engineers also became vital members of our team.

For the teams on which I worked, the fastest way to be accepted by the experienced engineers is to both listen and contribute. You have learned some new techniques and concepts, look for ways they can contribute to the project. If your thesis was something that could help, have an informal presentation to those who would be interested.  Be involved in the code reviews of more experienced engineers code, you probably will learn many important concepts that were not taught in school but is only learned in industry. You may also be able to share some techniques that you did learn in school that would be helpful to the project. Work on overcoming stereotypes. Not all experienced engineers are rude, just like most newbies are not obnoxious. If we are on the same team, we need to work together to produce the best products we can.

Posted in Agile Methodology, Attitude, Code Reviews, Computers, Fulfilling Life, Goals, SCRUM, Software | Tagged , , , , , , , , , | Comments Off on Are all Experienced Engineers Rude and New Engineers Obnoxious

Agile Manifesto

Posted on 14 March 2017 by Wayne Cook

It is best to understand a little history behind the Agile Manifesto to comprehend what the intention of the seventeen authors of the original manifesto was.  My link to one of the authors goes back to when I worked at Tektronix in Oregon. It was a great time to be in the software industry. Structured Analysis/Structured Design was the method of choice for most new development. As much organization as that brought to the software development process, people started to realize that software development should be more focused on delivering what people want and need instead of a massive amount of documentation. We were a very young team at the time given the task of developing the next generation of graphics terminal (Tektronix 4112/3/4). Because of all we learned on this project, the team started pushing for an even more interesting project for a stand-alone workstation that featured artificial intelligence (Tektronix 4404). My portion of both projects was to develop the Internal Diagnostics to help the field diagnose any problem that may occur with the hardware. Eventually, even manufacturing adopted my framework. Ward Cunningham was the Principal Engineer at Tektronix for our projects. The first language put on the Artificial Intelligence System was SmallTalk. With the merger of Object-Oriented programming and a desire for a more streamlined development process, Ward Cunningham developed Extreme Programming and eventually founded his own company. He was one of the software architects  invited to the meeting in Snowbird, Utah to develop the Agile Manifesto.

Manifesto for Agile Software Development

We are uncovering better ways of developing  software by doing it and helping others do it.  Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on  the right, we value the items on the left more.

Principles behind the Agile Manifesto

Each person who adopts the Principles behind the Agile Manifesto must internalize these principles. My internalization of these principles is:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software – To make a project successful, the customer must love the final product. The best way to do this is to have incremental “done” products that the customer can determine if the project is progressing towards the desired solution. Communication and demonstrable results are the key to completing the product to the customer’s satisfaction.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. – As customers see the results of your incremental implementations, they most likely will want “tweaks.” Changes between Sprints are far less costly than changes of specifications within a Sprint. The customer needs to be satisfied, but the team members need to also be protected from interruptions during each Sprint.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. – Work should be delivered at the end of each Sprint. This is why Sprint planning is so important. Have plans for each Sprint on what can be delivered and presented to the customer at the end of each Sprint.
  4. Business people and developers must work together daily throughout the project. – Daily meetings should be short and to the point. The Project Owner and the Team Members should be involved in the daily meetings, the Scrum Master runs them. If necessary, representatives of the Stake Holders can also be included. See the list of Scrum Roles for more details of who is involved.
  5. Build projects around motivated individuals. – Projects always progress better if the customers and the team are enthused about the project.
  6. Give them the environment and support they need, and trust them to get the job done. – No one likes to be “micro-managed,” so trust the engineers to do what they promised for each sprint. In return, the Scrum Master must provide all the needed tools needed so each team member can complete the promised stories for each Sprint.
  7. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. – True.
  8. Working software is the primary measure of progress. – Each Sprint needs to deliver incremental working software that the customer can see you team’s progress. Testing the code is essential before delivering the application.
  9. Agile processes promote sustainable development. – The Agile Process removes a great deal of the overhead associated with earlier processes, which frees the engineers to be more productive each week. Many studies show that working more than 45-50 hours per week actually decreases productivity and increases errors. As a team works together, they develop a good sense of how much they can accomplish each Sprint. People need to improve their productivity and take time to “sharpen their saws.” Without burning out, teams can be productive for long periods of time (many Sprints).
  10. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. – See the answer above.
  11. Continuous attention to technical excellence and good design enhances agility. – Time has to be set aside for improving each team members techniques and knowledge of what tools are available to help each team member be more productive. One tool is code reviews so each team member can learn from the other members of the team.
  12. Simplicity–the art of maximizing the amount of work not done–is essential. – Do what is essential to produce an excellent product. Do no more.
  13. The best architectures, requirements, and designs emerge from self-organizing teams. – Each team member brings tremendous skill to the whole team. Use those skills. With a final goal firmly in place, teams can develop a superb architecture that meets the needs of the customer. All team members must be included from start to finish of each Sprint.
  14. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. – At the end of each Sprint it is good to review what went well and what can be improved and how it is to be improved. Reflection is needed to make the team better. The team is collective responsible for the quality of the product, therefore each member must continually improve and help each other team member to improve also.

What Agile is NOT!

“On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto.” – from History: The Agile Manifesto. At Hewlett-Packard, there was quite a bit of enthusiasm for this new “agile” methodology. Unfortunately, there was a tremendous amount of misunderstanding of what the Agile Methodology really was. When I first heard another engineer tell me about the new methodology, the engineer described it as “three or four engineers gathering around a computer and banging out code until it was complete, no more need for design, code reviews, or test.” This sounded more like seat-of-your-pants programming than anything I had done at either Tektronix or Hewlett-Packard. If I had know that Ward Cunningham, and eventually Rebecca and Allen Wirfs-Brock were involved, I know that I would have done a lot more research. This was nothing like what was developed at Tektronix. Good quality code that satisfies the needs of the customer is the key. There still needs to be a long-term and short-term plan, identifying what goes into each Sprint. The plans need to be flexible to meet the customer needs, but there needs to be a known direction to all development. Each Sprint includes planning, analysis, design, coding, testing, documentation, and customer acceptance. Each story is not implemented until all these steps are complete. The statement made about the agile methodology does not meet the criteria set forth by the Agile Manifesto. The purpose of the Agile Methodology is to produce the best possible solution for the customers with the least amount of unneeded requirements being placed on the development team. Enjoy your development.

Posted in Agile Methodology, Attitude, Code Reviews, Computers, Goals, SCRUM, SCRUM Methodology, Self-Worth, Serving, Software, Uncategorized | Tagged , , , , , , , , , , , , | 11 Comments

Code Reviews in a SCRUM

Posted on 6 January 2017 by Wayne Cook

This is a little different than many of the items I have posted. But I do have four basic passions: Family, Computers, Health, and Personal Growth/Education. Today, I was thinking about SCRUM and how it relates to past software development methodologies. Since I do usually limit these posts to a single major topic, today is SCRUM and Code Reviews.

Too often people think about a Code Review as a tedious, draw-out event that really has no place in a SCRUM. As I study the Agile process, I am realizing that code reviews are agile also and are an important part of a SCRUM. As Jason Cohen points out in Scrum and Code Review — they go together like beans and cornbread, Ken Schwaber and Jeff Sutherland (the co-founders of SCRUM) say that code is not “done” until it is code reviewed. As a side note, I would highly recommend Jalapeno Corn Bread. Making your code reviews a little more enlivened would not be a bad idea also.

In the 1970s and 1980s, structured development was desired. Structured Analysis and Design was developed to overcome the haphazard development methods used before then. Using SA/SD, every stage was very formal and required so many steps that the overhead prevented meaningful work to get done in a short amount of time. Because of this overhead, Agile programming came into favor. How can work be done in a reasonable amount of time? Unfortunately, some people thought that code reviews are part of the overhead. It is interesting that Ken Schwaber and Jeff Sutherland, the developers of the SCRUM methodology, believe that code reviews are a vital part of the process. Code reviews often help find overlooked problems that could cause havoc later. They can also be used for educating new members of a team. Since the same person does not always work on the same piece of code, it is good to have several people aware of many sections of code. Code Reviews also help improve the consistency of code, improving “best practices” in coding and documentation, and increasing good communication within the team.

I like limiting the reviewers to one or two people. In reviewing critical code that affects many members of the team, larger reviews are required. In this case, I would suggest making this review a separate task or story to make sure it is done correctly. The purpose of the code review can vary. If the developers are new to the development environment, the language, or the application, it is good for a more experienced member of the team to review the code to identify common mistakes of newbies, to share algorithms that work well in the desired environment, or help improve the readability and compactness of the code (no, those are not mutually exclusive). If the developer is experienced, the newer member of the team can learn from the experienced developer and ask questions/make suggestions based on knowledge gained outside of the organization. Even more experienced engineers need to continue to learn.

The most common benefit of having a second person look at code is to spot problems that the developer may not see because errors not seen immediately become part of the “background” and are often overlooked until something in that section of the code changes. It is also much less expensive to find problems in the early stages of development instead of when the code is actually released. Remember that the same person does not always work on the same section of code. Having familiarity with different sections of the project helps each member be able to work on more sections and have a better knowledge of the entire product.

Where mutual code reviews are essential are dealing with code interfaces. If one developer has a function that is called by a second developer, they need to verify the calls match, that any “corner case” will not cause a problem, and that all the caller’s needs are handled properly by the called function.

Code reviews are to verify the functionality and help with the maintainability of the code. If coding tasks are kept to an average of one day to complete, code reviews are  a small part of that time and help improve the quality of the final product. To be “Done” a code review must take place.

Posted in Agile Methodology, Code Reviews, Computers, SCRUM, SCRUM Methodology, Software | Tagged , , , , , , | 7 Comments