Sunday, May 18, 2014

Mythical Man-Month Chapters 1-5

I started reading The Mythical Man-Month by Fredrick Brooks– a near 40 year old book about software development teams and timelines. The underlying idea is that you cannot just throw workers at a project and expect results. I heard about this book a while ago, but I couldn’t ever track it down at a library, nor could I find someone who would let me borrow it and to be honest, I didn’t want to pay for it. Just recently I found someone who would loan it to me. The book is old, and there are some parts in it that help show its age, but the underlying concepts are there and go into more thought than I’ve ever had about them.

While I’m only a few chapters in, as a developer, it has been quite depressing for me. There’s a section where it talks about the productivity of developers, and brought their salary into play. The developer who makes twice as much as the other is not twice as productive. The developer at twice the salary may be ten times as productive!

It is an interesting time for me to go through this book. I’ve been at my current workplace for just over a year, and I’ve been with my project since its beginning. I’ve seen developers come and go on the project. Team leads, and project managers moved around. At one point, we had 11 workers on the project full time, and in less than a week the team will have six. The number fluctuates, and the team looks very different than when we first started.

For the most part, the team has worked well together. I believe that is because of each individual’s ego is inline. Mythical Man-Month compares development teams to surgical teams. Each person in a surgical team has a specific task. One person may be deciding how to split away something, another person may be splitting that into smaller more manageable tasks. Another could be actually doing those tasks. Then there are the individuals who are helping support those actually building, such as secretaries, and managers who will be gathering information from your client. This works because everyone knows their role, and follows it.

So why did the beginning of Mythical Man-Month depress me? Because I’m seeing the concepts in the book come into play and be accurate. Developers are optimists, and they’re horrible at estimating. The money wasted on bringing new people on board only to see them go has costs go through the roof without positive impacts on the team. Furthermore, I am now thinking about if I am as good of a team member as I had thought, my place on the team, and what I’ve been doing to improve it.

It also depresses me a bit because of the approach to software design, and how ends up in the end user’s hands. For example, our product owner will request some report. The team will gather information on said report, by asking questions, doing some database research and basic proposals. Everyone will agree that this report is important and it needs to be generated a certain way. While in the middle of actually building it, suddenly the requirements will change. For me that is extremely depressing. I feel that it shows a lack of planning and respect for the developers’ time. Mythical Man-Month touches on a related topic when it goes into talking about focus and effort. A feature that may be used once a quarter can take a long time to build. What if those efforts went into something used every day? I’ve seen problems like this throughout my career, and it makes me stop and wonder about where my energy should be placed.

Thursday, May 15, 2014

Scrum: A Breathtakingly Brief and Agile Introduction

I’ve been on a handful of scrum teams. I understand scrum and I like scrum. I’m not going to go into the strengths of scrum, or the negative points (unless painfully obvious in the book) of scrum. I’ve done other agile types of development, but scrum seems to be the strongest for the corporate world in my opinion.  With that said, I’ve never been on any team that fully follows scrum. There’s always subtle variations to it that the team needs. The basic ideas are the same though.

The book is short, and you can read it in a half hour. I think it is a great introduction to scrum, and some of the basic goals from all points of view. I would recommend this to anyone who has not been doing scrum, or wants to know more about it. If you’ve done it on a couple of teams, there will be nothing new for you.

The book starts out talking about the types of team members. There are three – the Product Owner, Scrum Master and Team Member. The one I found interesting and I think needs to be addressed is the Team Member. Team Members need to be cross functional in my opinion. The book talks about specialization but later retracts it a bit.

  • “People who do the work are the highest authorities on how it should be done.” This to me brings to light one of the biggest downfalls of scrum, and that is poor architecture is often a result of scrum. When a developer has a misunderstanding of the ultimate goal, or different point of view, this can lead to poor decisions with architecture. You also must remember that not all developers are strong in the architecture area
  • Doing my job vs. Doing the Job – The ultimate statement of being cross functional. It doesn’t mean you have to be an expert in all areas of technology of the product, but you need to be able to do it.

This goes back to my cross functional team members. I believe that scrum is under the fundamental understanding that nearly everything is able to be completed by any team member. Sure there may be a few things that are an exception, and not everyone will be on the same level, but everyone needs to act on the best interest of the team.

The book brings up burn down charts. Burn down charts are awful any time the scope changes. For example, if my product owner comes to me and adds 6 hours of work to the sprint, and I complete 8 hours of work the same day, according to the burn down, it looks like I only did two hours of work. Additionally, you show me a release burn down where there isn’t a story added. When a story is removed (say it is no longer necessary) it looks as if the team did a great job! I much prefer the idea of a burn up chart.

Meetings vs. Ceremonies – I forgot about the “ceremonies” title. At first, a major selling point of scrum and agile was less meetings. I was sick of having meetings every other day to discuss status on work. Those meetings were an hour or longer. With scrum you have more frequent, but shorter meetings. Probably a wash in reality.

Sprint Planning – I’ve never done scrum with a full time product owner. Having a dedicated resource to be a product owner is expensive. As a result, I’m reminded that I’ve never done sprint planning as efficiently as it could go. The book divides sprint planning into two parts that I don’t necessarily agree with, but I understand what they were going for.

  • Part 1 (What will we do.) – The product owner decides what stories will be considered for the sprint. To me, this is pointless. The point of the prioritized backlog is the indicator of what should be done. This step only exists because product owners do not keep the backlog up to date.
  • Part 2 (How we will do it.) – The team breaks up these stories and tasks them out. The product owner is available for questions on how to do this. I’ve never had a product owner regularly available during sprint planning. As a result, I believe developers need to groom the stories early to help understand the stories. This will not occur during any “sprint ceremony”, but needs to be a regular occurrence. This will also help understand the end goal of the system. The problem with my preference is that it does take a lot of time.

These are based on my experiences and opinions of scrum. Like I said earlier, every scrum team has their own obstacles that won’t work in the textbook definition of scrum. Scrum is about small teams. And if you don’t have a small cross functional team that can be trusted, you’re in for trouble down the road.

Monday, April 1, 2013

Async and Parallel Programming in .NET 4

I spent some time recently on some of the latest features of .Net. One area I overlooked a while back was Async and parallel programming. I've done mostly web development and it hasn't always been beneficial to me. Lately I've expanded my talents, and this has come into play.

Essentially the Task Parallel Library (TPL) helps add parallelism to your application without having to worry too much about your thread pool or exceptions. You have to worry about these things, but the TPL has really helped out in the simplification of these areas. This is important because as technology advances, our applications need to be more snappy. For example, on the Windows Store applications, you may have multiple threads happening, but you cannot lose responsiveness to your application. Microsoft will reject your application if it does not respond.

Tasks are the fundamental building block. I think of tasks as function that will consume a large number of CPU cycles or require information from a third party. If we had a single threaded application, we'll be forced to wait for these functions to complete. However, we can create a task that will start up another thread and we can go on our doing other things.

As always with multi threading, there is additional complexity versus having a single threaded application. The TPL helps handle these issues. Each task will have a status, a result, and an exception that can be checked for processing. How variables are passed into tasks will impact your results. The order of execution can also be impacted because of multiple threads running at the same time. The TPL helps you handle it all.

I'm going to spend some time focusing on a few different areas of the TPL and show how they may be able to help you out in development.

Friday, February 22, 2013

Securing Information In Your Database - Introduction

As a security precaution, it is important to not save any sort of sensitive information in clear text in your database. This can be information such as an email address, a social security number, answers to secret questions – or anything that would be considered sensitive data for the user.

For most people, it is surprising how a little bit of information can lead to malicious attacks. They use the same account names, emails, passwords, and secret questions for all of their accounts, so if you get one, you probably have them all.

I’ve seen an unfortunate amount of sensitive information stored in clear text from applications I have worked on. When I ask why it is done this way, no one has an answer. The response is always “it is just always the way it has been.” I don’t find this to be an acceptable answer as when you do your initial design, you know it needs to be done.

My next few posts will talk about encryption, hashing, and security in general. 

Sunday, July 1, 2012

Pro jQuery - Chapter 4 (JavaScript Primer)

It took me forever to go through this chapter. It was incredibly slow, and nothing too interesting. If you're reading a book on jQuery. jQuery has its bases in JavaScript, so a key foundation for it is JavaScript. Plus a lot of it was so long, with many examples that I went through on principal that it just got me really uninspired. I am glad to have finished it.

So it uses a lot of console logging, and created objects for its own demonstrations. It went into how you'd add a method onto a function, which is very different from how you would in c#. It was actually very good at explaining how to determine if an object has a property, explaining the differences between null and undefined. I spent a good portion of my time on this since it is a little different from c#.

The book did touch on array methods, but didn't go into depth. I'm glad about this because as I said earlier, it was longer than it needed to be.

So they had to put this chapter in for sure, but I feel that it was still a little long. It isn't really going to be of any assistance if you have a problem. You're going to need to go to another JavaScript reference and look at it there.

I am excited though because I see the next part is called "Working with jQuery".

Sunday, June 24, 2012

Syntax Highlighter - Show code directly in your Blog

You may have noticed that in the recent gridview radio button blog post, that I had code formatting directly in the blog post. This is something that you cannot easily do with blogger. Bummer. I recently came across Syntax Highlighter, and it allows a syntax highlighter to be implemented into any web page (or blog) with a few lines. It works for a number of languages, and is open source. I really like it so far.

Friday, June 22, 2012

RadioButtonGroup Across Multiple Rows in a Gridview

At work, I have a grid view, and in that grid view, every row is a different option. .Net is too smart for its own good in this case, as it puts every radio button in its own group rather than allowing you to use the same group along multiple rows. As a result, when you go to use the radio buttons, they do not deselect the previous selected option. So I thought about this from my point of view. How would I break it down?  Here's what I came up with.

Loop through every row, and find the radio button you want, then turn it off. Go back to the radio button that was originally selected, and then select it. We can do this because we can go back to the sender, find it, and modify it. Here's the code that does it:

protected void rdoPolicy_CheckedChanged(object sender, EventArgs e)
      RadioButton sendingRB = (RadioButton)sender;
      sendingRB.Checked = true;


private void DeselectRBButtons()
      int x = 0;
      foreach (var gridviewRow in grdPolicies.Rows)
          var rb = (RadioButton)grdPolicies.Rows[x].FindControl("rdoPolicy");
            rb.Checked = false;