My opinion on daily stand-ups

Wow...i Have completely failed to keep writing in this blog at all. A lot has changed since I've lasted posted. New job, new house, new projects. But that isn't what I'm going to be writing about today. Today I'm going to be writing my thoughts on daily stand-up meetings.

I hate them. Dear god do I hate them.

I understand there are different ways to do a stand-up meeting. The stand-up meeting I've actually experience is the standard run of the mill variety I see posted online on how to do stand-up meetings. Everyone standing in a room, and one by one what they did yesterday, what they are working on today, and if they have any estimates on completion time and if there are any problems.Here are my grips with this

1) "Did you do your homework"

When I'm asked what I did yesterday, I'm reminded of my mother making sure my homework is finished before I started playing video games. I shouldn't have to remind the team what I'm working on, much less what I've accomplished. Even what I'm working on is relevant to another teammate's work, in which case they are probably aware of what I am doing as long as there is good communication, or it isn't, in which case they don't need to worry about what I'm working on. I don't need my hand to be held to make sure that my work is getting done. If a daily stand-up is needed to make sure someone stays on track, that person probably isn't a good fit for the job.

2) "It is OK if I got nothing done?"

We all know the song, "99 little bugs in the code, 99 little bugs...take 1 down patch it around, 136 bugs in the code." When asking what I've done the day before, an acceptable answer better be "found yet another way to bring down the SQL Server". It's code, not physical labor. Some days nothing gets done. Code should not be written just so one can say they did something. I'd rather have someone write no code for a week, instead thinking about how it should be done, investigating different possible ways to do something, and then spend maybe a day or two writing code, than someone who writes off the top of their head and then a month or two down the line it needs to be debugged. Having to say that I haven't accomplished my task for five straight days is just depressing. Especially when the other team members may not be quite familiar with the code you are working on. We all had that though about another coder that took a bit too long, "God he is so slow, I could do this task in half the time." No, we can't. There is a nasty edge case that really screws with the code that we are unaware of. Having to justify why you accomplished nothing the day before just encourages either bad code for the sake of being able to accomplish something or lying about what was accomplished.

3) Nagging

"Is it done yet, is it done yet?" No I have no idea if I'll be done today or tomorrow. We all think it'll take just 10 minutes to write some code, then that nasty edge case from above rears it's ugly head and now you aren't done until two weeks later. It is tough to estimate how long code takes to write (correctly that is). In my opinion it should never be done in days. At a minimum it should be estimated in week or even month increments. Days are too hard to predict. And, please never give an estimate of completion in percentages. Because the first 90% of a project takes 10% of the time and the last 10% takes the remaining 90% of the time. So saying you are 45% done is ultimately meaningless.

4) Encourages bad communication the rest of the day

I've heard someone tell a coworker to bring up an issue in the next day's stand-up. This was at 11:15 in the morning. So half the day the question didn't get answered. That's a half a day wasted in my opinion. Having a daily stand-up brings up opportunities to ask questions or discuss potential roadblocks, or find someone who can help. It is one of the three core questions. (What did I do yesterday? What an I working on today? What are any roadblocks I may have?). But that is a problem, if people feel that is when these issues will be addressed, they've wait until then to address them, instead of getting them addressed right away. Or even try to find the answer for themself if they think someone else has the answer.

Not everything about daily stand-ups are bad. There are a few good points.

1) Being in the know

This point isn't about knowing what everyone is working on. It is more about knowing what is going on at the higher levels. Having everyone in the same room allows for announcements. New employees starting? Special events coming up? Sure you can email announcements, but some people get a ton of email and it may get lost in the shuffle.

2) Priority shifts

I'm talking about major priority shifts. A new project, or sub-set of a project needing more attention. Maybe some task isn't as important and you can let other teams fight to have extra engineers for their tasks, Thunderdome style. This does not include asking a developer to work on a bug different from the one he is currently working on. You can find him at their computer and let them know of that small shift.

And...that's really all I can think of that are good about the standard "daily stand-up". If anyone ends up reading this they'll probably think I'm just someone who either doesn't get it or that I haven't been in one properly done. I prefer the weekly or bi-weekly meeting, where there is a giant spreadsheet and things are crossed off that are finished and the rest prioritized right then and there. A 1-hour weekly meeting actually takes less time than five 15 minute meetings. And I'm only interrupted once in the week instead of worrying every day about how I'm going to explain how I spent the previous day refactoring a method to make it easier to work with because running the debugger thru it was like trying to get a hyped-up 10 year old to go bed.

I guess some people like daily meetings though. If they work for your team then they work. Can't argue with results.

Too lazy to post my own stuff

I've haven't got, or had, anything interesting to write as of late. So, here is an interesting article I happened across during the travels around the interwebz. Enjoy.

Coding is not the new literacy

Guilty Pleasures of an ex-hardcore gamer

Recently I've been enjoying causal games. I play them for easily two hours or more a day now. I prefer playing them on my kindle, but there are some I have to use my iPad for. It pains me to enjoy these games because I used to consider myself a hardcore gamer. It is even possible to be a hardcore gamer of causal games?

While some of these games can entertain me for hours, others feel incomplete. The promise of gameplay is there. But it's like the developers did "just enough" to be able to call it a game and put it up. Most of these games fall in the realm of "play for about 5-10 minutes, then wait a full hour or until you can do something again". Other games are just complete rip-offs of the already successful games.

The quality for each game is vastly different too. From the occasional hiccup in a game that cause it to crash or application destroying bugs that can only be fixed by completely reinstalling the application, and thus losing your data (which is totally not cool since nearly all the games have micro transactions and you can lose any of those purchases if the transaction was of the ones where you buy in-game currency and the game isn't played or saved on a server). I've had to stop playing more than one game on account of these kinds of problems, which saddens me because at least one of the games this has happened to me with I really enjoyed.

Anyway, here is a list of casual games I currently enjoy playing:

Family Guy: The Quest For Stuff, Puzzles and Dragons, AdventureQuest: Battle Gems, The Secret Society - Hidden Mystery, Book Of Heroes (some parts of it count as a MMO, but the energy system pretty much makes this a casual game), Theme Park, Minion Rush, Spider-Man Unlimited, Jurassic Park Builder, Honorbound, and Plants vs Zombies 2.

Wow, that's quite a list. No wonder I spend so much time playing on my Kindle/iPad. That doesn't include the pinball games I play or all the tiny games I play on these devices (hidden object games, digital game books, etc.).

Perhaps I am a hardcore causal gamer.

Nothing gets coded before 2 am

I'm not sure what it is about the night vs the day that makes me feel so much more motivated to code. Maybe it is because the day is nearly over and bedtime is approaching and I have things I need to finish, which makes me sit down and actually finish the tasks I have set out for myself. The whole procrastination thing that goes on that lets people do less important things. I also tend to want to keep the things I really want to do for last. Even while playing video games, I do the more chore-like tasks before the really fun ones, like getting a certain number of kills with a pistol, just so I never have to use the pistol ever again. Unfortunate that I'm also pretty tired and reading a computer screen hurts my eyes, making it hard to code even though I have a good amount of motivation right now.

Decided to read a book on MVC

I've decided that I should read a book on .NET MVC. I'm at a crossroads for which one to get though. There is Professional ASP.Net MVC 5 from Wrox (which I commonly call the red books) and Pro ASP.Net MVC 5 (Expert's Voice in ASP.Net), which is from the publisher Apress (whose Expert's Voice series I refer to as the black books). I have Professional ASP.Net 4.0 in C# and Visual Basic from Wrox and I really thought it was good, so my initial reaction is to go with the red book. But what if the other one is better? I decided to look up the authors for each book. The red book version of MVC has four writers, Jon Galloway, Brad Wilson, K. Scott Allen, and David Matson. The black book version has only one writing credit, Adam Freeman. After a very quick search, it seems like the better choice is the red book. Adam Freeman has written a lot of books, but the other authors, at least Galloway and Matson seem more active with podcasts and blogs. I could be wrong, it was a very quick one minute goggle search on each author. I'm going to go with the red book for now, but I would be interested in getting the black book too and seeing the differences.

I'm...not going to let you do that

I was currently working on some error handling code for one of my side projects when I came across this problem. I have objects stored in a database, which of course has a field Id for its primary key. However, when the user goes to create this object, the Id field has no value until it gets saved to the database, as which point the database engine gives it an Id. The object in my code includes a member for the Id field of type int? (which is a nullable int, it can have a value of null). The function I use to get the object from the database is defined as such

     public Object GetObjectFromDatabase(int? ObjectId) { }.

Inside this method, if the value of ObjectId was null then I would return null as the object.

     if (ObjectId.HasValue)
     {
          // Get and Return the object
     }
     else
     {
          return null;
     }

Adding in my error code, I thought about that behavior and decided that if I was going to the database to get an object, I would need to know its Id, so I decided that passing in a null would be considered an error. So I changed that else statement to read

     else
     {
          throw CustomizedError;
     }

I still wanted the function to accept a nullable int to avoid checking if there was a value for Id and then convert it to a regular int for every place I call GetObjectFromDatabase. I have other functions that take in similar parameters, including updating the object, deleting the object, and other various things that can be done with the object, After some debate with myself, I changed those functions to only accept a regular int instead of a int? for three reasons.

1) Programmers can only make mistakes when the code allows them to. This is why we have private variables and enforced type checking. In languages like Javascript, bugs arise when strings get treated like numbers and vice versa. Javascript doesn't force the programmer to choose a type for thier variable and stick with it. It's just var Name; Take the following code
  
     var Two = 2;
     var Three = "3";
     alert(Two + Three);

The pop up you get will display "23". This would be a bug if the developer wanted 5. It's a simple mistake, but it happens because it was allowed to happen. If you tried that in C#, you wouldn't be able to compile. If I don't want programers to pass a null into this functions, I just need to not let them at all.

2) Bugs make it through testing all the time. I or someone else will eventually make the mistake of passing a null into that function, and, if I had testing for my project, since it would be a special case there is a good chance it would make it through testing.

3) It is always better not to have to throw errors. Even if it means more code to write. Sometimes having to write more code means you have to think through what you are doing. Also, bug-free code is sort of the goal and writing code that actually prevents bugs before it even compiles is preferable.

Book Finished: Mythical Man-Month

I just finished reading Mythical Man-Month by Frederick Brookes. It was pretty good, although a bit dry at times. It is a bit dated too although the 20th Anniversary Edition tries to updates the old material with a new chapter that includes discussions with others on the original material. Some of the points I took away from the book that I think are still applicable today for software projects are:

     - Adding people late in a project makes it late, or makes it later if it is already behind schedule. There is an initial overhead cost of training and the new worker to find their way and become familiar with the  project before they can fully contribute to the project. If you need more people, add them sooner than later to mitigate that cost.

     - The system architects and designers should stick to only architecture and designing and the coders should only stick to coding, that may you have a separation between design and implementation, otherwise implementation may influence or change the design to fit the implementation, which may cause problems with what is intended or if a decision is made to change platforms.

     - There should be as few designers and architects as possible, or at least as few people making decisions as possible, in order to preserve conceptual integrity and uniformity.

     - Communication is the hardest part about working on a team. The effort to communication and coordinate grows exponentially as the team grows in size. This means that doubling the work force will not double the productivity because the effort of communicate will more than double.

     - As much documentation as possible should be completed before any other work starts on a project. Writing documentation forces you to make decisions and ask questions you would otherwise put off or not know you had to make or ask. It is easier to implement things from the start rather than add them in later.

     - Despite the above point, the only real constant in a project is change, and so one must plan for changes to occur, not just in specifications in the project, but also for changes in the organization or the team performing the work.

     - Milestones need to have a clear and precise definition, otherwise confusion about progress may arise. If the definition is precise you cannot lie to yourself about progress and a person receiving a progress report will have close to the same understand of the progress as the person giving the progress report.

I've seen this book on a few required reading lists that some software developers have up on various blogs and website. I think it is worth a read as long as you pick up the 20th anniv. edition so you can understand what may or may not be still be applicable.