Should we store generated files?

Unfortunately, the answer isn’t as simple as yes or no.

I suggest asking yourselves a few questions to help you determine whether it makes sense to store the generated files/resources.

Does storing these files/resources hurt you or your team in any way?

Are you running low on storage space because of these files?  Often the sheer number of these resources can become unmanageable, especially when you start looking at the space they are consuming in source control.

Does it take extra effort to actually store these resources?  If your team needs to go through extra steps to ensure that these items are being stored, they may be a candidate for dropping.

Does the existence of these files confuse people?  When I first started working with React.js, we stored both the source and the generated files.  I didn’t know what the difference was, or where I should be making changes.

Does it take longer to store or retrieve files because of the number/size of these extra files?  This may be hard to discern.  One way to get a feel for this is to simply look at the amount of storage dedicated to these temporary/generated files compared to the rest of the files.  If it seems a large portion is generated files, perhaps you could try removing them from the storage (maybe in a test location).

Are they easily reproduced?

Do you have an automated way to regenerate these files for individual developers? Ideally, the answer is yes (or at least nearly automated).  This could include a step in the build process (that you execute locally when you make changes, or is kicked off auto-magically), or a process that is waiting in the background for someone to make

Does reproducing them happen quickly? If the answer is no, then it might make sense to store these files.  If the files need to be regenerated often, though, even though the process takes time, it might make sense to not store them, as the stored files will be of little to no value.  If this is the case, then I would invest some time in ways to speed up the generation process, or remove the need for the files all together.

Can an individual reproduce them on his/her machine?  Sometimes files need to be generated on a machine with a certain setup (OS, applications, etc) and there are only a few of those places available.  If this is the case, then it might make sense to store the files, especially if they don’t need to be reproduced often.

Do the files need to be reproduced often?

If you need to reproduce the files often, because you are changing inputs, or changing environments, then you probably don’t want to store them.  Storing them is buying you very little in this case, since you will likely reproduce them and overwrite what was previously there.


Is it bigger than a breadbox?

In the waterfall method of project management, we are asked to estimate how long a large piece of functionality will take to complete.  Then, all of those parts are added up to get a timeline of when things will be done, and we’re off.

As humans we can estimate how long a small, simple task will take relatively accurately.  When that task becomes larger, and/or more complex, we rapidly get worse at estimation.

Agile methodologies ask us to break the tasks down into smaller bite-sized pieces, which allows us to more accurately estimate how long a task will take.  If this is true, then why do people still do relative sizing in agile projects where the tasks are broken down appropriately?


Where both of these systems fail is when you take into account who is doing the work.  We all know that each developer works at a different speed.  There is often a strong correlation between the speed at which a developer can complete a task and their experience level (though, there are certainly times when this is not true).

So, now let’s imagine that we have a team of 5 developers and a rather large project we want to complete.  When we go to estimate, who’s estimate do we take?  Do we go with the lowest estimate, the highest, an average?  Do we divide the work up among the developers and get them to estimate the work they are assigned and hope we divided fairly evenly?  What about vacations, sick time, or someone leaving the company?

Relative sizing to the rescue!

Ok.  So, like anything this is not a panacea.  It works, but it takes effort and commitment to make it work.  Let’s start with a definition of relative sizing.

Relative sizing is simply the process of looking at the stories and determining how big a task is in comparison to other tasks.  The nice thing is most people will agree that task a is smaller than task b most of the time.

When doing relative sizing, most teams pick some series of numbers to assign to the sizes (we used powers of 2, others do prime numbers).  When picking numbers, I suggest not using 1,2,3,4… since this is too fine grained (you want some wiggle room).

Now that you have a scale, each team member can give estimates on tasks using these numbers.  When there is a discrepancy between team members, use that as an opportunity to discuss why there are differences.

Sometimes the difference is because the task is unclear, and this gives you an opportunity to clear up any possible misunderstandings.  Sometimes one developer knows something the others don’t and he/she gives a very different estimate.  This is a good learning opportunity.  Sometimes you will have very small discrepancies, like one developer estimates a 2 and the other a 4, there may not be any differences in understanding, just one thought it was bigger than the other, in that case we typically went with the larger estimate, though you can make your own rules.

You may be wondering how assigning tasks points is going to help you determine when a project will get done. Good! Because I haven’t shared that yet.

After you have points assigned to your cards you will need to plan out a couple of iterations (a defined period of time to do work, often 2 weeks).  Ask the developers how much they think they can do in this iteration and only put in the tasks they think they can accomplish.  After a couple of iterations, you can add up the total points the team completed and take the average.  That will be their velocity.

You will notice when a team first starts out their velocity will probably fluctuate as they get used to estimating and working on the new project.  Be sure to keep an up to date feel for their velocity.  I would recommend not using all of the previous iterations for the average since you may have some anomalies especially at the beginning.

With their velocity and the stories estimated for the project, you should be able to project when a project will be complete.  And, you don’t have to go to all of the trouble of assigning out tasks to individuals!


Bad Code – Snippets from production

True, false … or maybe?

Lets start with something on the funny side. Some of the code that I have come across in our system.

boolean isFutureDeal = Boolean.parseBoolean(request.getParameter("loadFuture"));
if(isFutureDeal != true){
       isFutureDeal = false;

If it’s not true, set it to false. I guess this is to make sure it isn’t set to that other boolean value – true, false, maybe.

Give me that.  What?!  I don’t need that.

public ShoppingCart createNewCart(ShoppingCart cart, HttpSession session,
                     MiniUserBean member) throws Exception {

              if (cart == null) {
                     session.setAttribute("shoppingCart", new ShoppingCart());
                     cart = (ShoppingCart) session.getAttribute("shoppingCart");
              cart = (ShoppingCart) session.getAttribute("shoppingCart");

The cart object is passed in, but the first thing we do is read it from the session, so why even pass it?

Day of the week calculation

[pseudo-code...actually seen in production]
if (date == "11/28/2016" || date == "12/5/2016" || date == "12/12/2016" 
     || date == "12/19/2016" ...) {
          dayOfWeek = "Monday";
} else if ( date=="11/29/2016"...

You get the idea.  There were about 1/2 year’s dates in the if statements.  I found out about this gem when a customer called and complained that their script was not setting the day of the week any longer.  This was in perl, and I replaced that huge block with a few lines that would forever compute the day of the week.

Learning in the real world

How many times have you heard a kid say, “when am I going to use this in the real world”? How many times have you said it?

My niece is taking some programming courses in college and she told me she was having difficulty with one of the classes. When I asked, she said she just didn’t understand how what she was learning would be applied.  The professor had forgotten to tell the class the why of what they were learning.

This happens throughout our learning lifetime.  I wrote a post a while ago (Searching for the why) where I talked about making sure to include the why when talking about processes as well as coding techniques.  Knowing the why helps us to apply the how better.

Does knowing the why help us learn too?

I think understanding why we are learning a new skill helps motivate us to learn it.  Let’s take for example, learning a new language.  I have tried many times to learn a new language, and I have only been partially successful.  I was most successful learning some Spanish when I was planning on going to a Spanish speaking country.  Since then, it has been on and off.

I don’t know anyone who speaks Spanish.  I live in the midwest and we don’t have a lot of native speakers in the area.  I have little to no reason to learn it, other than I have this fantasy in my head of me being able to speak multiple languages fluently.

Sometimes the skill that we are learning is simply a stepping stone to something more complex, and having a concrete why for that may be difficult at best.  This happens a lot throughout our school years.  But, that is the why right there.  Because it is crucial to understanding something greater.

I encourage our teachers, our mentors and our parents to help the learners of the world to understand the whys of what they are learning as well as the whats and the hows.  I encourage our learners to ask the teachers they whys as well.