The FUN-duh-MENTALs
Friday, August 15, 2008 10:55:45 PM (Mountain Standard Time, UTC-07:00)
So tonight I got to help demo what a fishbowl was at the ALT.NET Canada (thanks Doc!) conference and the topic of discussion was on the Fundamentals of Software development. During the session I started to realize that what I considered to be fundamental seemed to be far from what others did. After a few discussions I started to think that the fundamentals were different based on generational divides.
I'm speaking for myself, but hopefully for my generation, but when I hear "The Fundamentals of .NET development" I think, Object Oriented Programming, Design Patterns, a knowledge of the syntax of a language, and at least a base understanding of what the CLR is and what it provides for us.
Some other takes on fundamentals were focused on understanding how the underlying operating system works, Algorithms and Data Structures.
This got me a little depressed because I don't have an intimate knowledge of how the underlying operating system works, or how to perform a deletion from a red-black tree, or how to implement a half decent hashing algorithm. Ask me to build an AVL tree and I might puke, or at least ask "why? it's 2008" I have a base understanding, but I'm not sure if that counts as the required fundamental knowledge to build a decent app.
When I was writing C, I cared a lot about writing well optimized code. I cared about memory allocation/de-allocation. I cared about protecting from buffer overruns. I cared about so many things, that I just don't think about, as much, now as a .NET developer. All the things I don't have to be concerned about allows me to focus on other things that I want to care about.
It seems like we developers are proud of being an expert at something, but when that something becomes less and less relevant in building applications today, we tag it as "fundamental". Perhaps in 10 years or so the next generation will wonder why they would need to understand object oriented programming to build valuable applications. After all it will all be written in DSL's, right?
Couple of more pennies for ya!
Ambiguous Reference: Castle.Core.Interceptor.IInvocation
Friday, July 11, 2008 9:08:36 AM (Mountain Standard Time, UTC-07:00)
So yesterday I had this idea on how to run a background thread using an interceptor, but first I needed to Grok how the castle interceptors worked. I quickly ran into a snag, it looked something like this:
The problem is that the latest version of Rhino.Mocks hasn't internalized the castle dependencies. So the compiler doesn't know whether I'm referring to Castle.Core.Interceptor.IInvocation from the Castle.Core.dll or Castle.Core.Interceptor.IInvocation from Rhino.Mocks.dll.
I'm not sure why this is, so I did a little digging. And found this post... In one of the last comments someone else had this same issue...
I'm not really sure what this meant, so I decided to pull the source from the trunk. In the Rhino.Mocks project there's a file called "ilmerge.exclude" and in it was the interface that I was having trouble resolving (IInvocation). I removed it from the file, and rebuilt a release version. Seems to be working now.... I'm still not sure why this change was made... which makes me feel a bit uneasy.
Try it at your own discretion.
Software Does Not Suck
Thursday, December 20, 2007 4:29:11 PM (Mountain Standard Time, UTC-07:00)
Ok so I have to admit that yesterdays entry cleverly titled "Software Sucks" was a little impulsive and over the top. Software does not suck!
I suppose I over reacted a little bit, but I think the reason I was so upset is because I want people to have positive experiences when working with software that I hand craft for them.
At Subway I love their concept of "Sandwich Artists" where they craft the sandwich right in front of you. You're there for every step of the process, minus the baking of the bread and prepping of the toppings etc etc...
What if software were built in a similar fashion? Do you follow where I'm going.. what if the end user was there for every step of development so that they get the software that they want. Now in an ideal world that would probably amount to bloated budgets and the never complete software. But what if we could get the end user to prioritize and pick the things that are most important to them and guide us as we build the software for them.
You are not doing Agile, you are Agile!
I was a part of an interesting conversation today with Sean and Adam where Sean brought up a great point. (Pardon me Sean if I paraphrase incorrectly!) In the eyes most companies, a software project was successful if it was on time and on budget. Until you can prove to the company how the inefficiencies in software are actually costing them money, you probably wont be heard.
So how does one go about creating change, well start with the all mighty dollar! Perhaps one tactic for introducing Agility into an environment is to discuss how it can save you money. I'm not a big fan of graphs and excel sheets and charts, but I've found that it's usually a good way to communicate with people who have money or are responsible for spending money.
So hit 'em up with a little "Agile vs. Traditional Cost Models" talk. Mr. Joe Ocampo says it best with:
"The quicker you are able to stabilize a production release the more you will increase the value stream for the business." - Joe Ocampo
Sean offers his thoughts on how to introduce change in your shop and why it's necessary. It's definitely worth a read.
With that said... my love of software development continues!
Software Sucks
Wednesday, December 19, 2007 2:51:15 PM (Mountain Standard Time, UTC-07:00)
Next month my family and I are moving to a new place. So today I made a list of people & companies that I needed to contact to update my address. I really only expected to take about an hour to update my address at 15 different places.
It turns out that this simple task of changing my address is taking me close to an entire work day. Why? Because "Software sucks!"
It's literally unbelievable how many hoops a customer service representative has to jump through in order to make this simple change. I just spent 20:04 minutes speaking with a customer service rep from SAIT to change my address. During that 20+ minutes I heard him say things like:
"It's not allowing me to save."
"It's saying you have a bunch of primary phone numbers."
"It's saying it's locked."
"I have to get a hold of a technical person."
What? I'm sure the first thing most people are thinking is that this person didn't know how to use a computer. Even if that was the case, which I don't think it was, why would he be made to use one then!? Would software actually be the correct solution to help him be more productive? I felt like this guy knew what was going on and was working towards my best interest.
I had the same issue while speaking with a representative from SHAW. I spent 11:05 minutes on the phone with this gentleman. He told me that because the address wasn't in the system he couldn't change my address. He had to send an email to a "technical" person so that they could add the address to the system, so that he could change my address. Does this sound crazy to you? Why is there this dependence on the "technical" people to get things done. IMHO, because "technical" people never gathered the necessary feedback while they were building the system. Software should empower it's users, not inhibit them!
The gentleman at SAIT noticed that there were a few mistakes in regards to my account so he took it upon himself to fix those errors. But in the process of doing so, he was stopped by several "technical" hurdles. Which I assume is the reason why previous customer service rep's didn't take action earlier. Because they saw "the technical hurdles" and knew that it would just slow them down.
As I was on the phone with this person I asked him questions like...
"Did anyone ask you for your feedback when they were building this software?".
His response ... "No! Why would they do that!?"
My response, "because you're the one using the software... maybe!???".
He proceeded to tell me about software and how it's built. He said they get these different consultants to come in and build different parts of a system. He said it was like getting 2 different groups to build each side of a bridge. And when they try to put the bridge together, it doesn't fit so they duct tape it together to make it "work".
He is so right, why is this the norm for software development? Why is it that we think it's ok to have to rely on our "technical" people to solve problems that shouldn't be there in the first place. If this gentleman's feedback was asked for during the construction of the software, most of these hurdles probably would have been addressed then. Maybe then... he could actually be the productive employee that he wants to be, and I can get a long with my day!
Who thought changing and address could be so hard!
The Captain Isn't Always The Best Player
Saturday, November 24, 2007 10:38:24 AM (Mountain Standard Time, UTC-07:00)
Pick a sport, any sport! Start going the rosters for different teams and you'll see that the captain of the team isn't always the person scoring the most goals, getting the most assists or on the top ten leader boards in the league.
The captain isn't supposed to be the best player. The captain is a person who knows..
- how to lead by example.
- how to bring out the best in those around them.
- how to stand up for others around them.
- how to listen.
- how to inspire greatness.
In software development it seems all to common that we have this notion that the team lead or project manager should be the best player on the team. They should know more about software development and every new technology coming out better then everyone else on the team. I don't think that's the case at all. In fact in most of those cases, it's likely that the "star" player ends up becoming the one person show.
There's only so much any one person can do, there's so much more that a team can accomplish.
"I may not be able to change the world, but I guarantee that I will spark the mind that will change the world." - Tupac Shakur
I really like some of Chad's thoughts on becoming a leader.
The Code Sucks, Not The Author
Saturday, November 24, 2007 10:29:05 AM (Mountain Standard Time, UTC-07:00)
One of the few things I've learned in the last few weeks is to not be so politically correct when it comes to sifting through code. What I mean is, if you spot a piece of code that can improved, then address it.
Don't hold back your comments because you're worried that the author of the code will feel attacked or hurt. There's also constructive ways of doing this, if you're intentions are to make someone else look bad or prove that you're a better developer then everyone else, then you've got some character flaws that probably need addressing.
If you spot code that smells deal with it. Explain why it smells and construct ways to improve it. You're not helping anyone by holding back your true thoughts. The only way you and your team is going to get better is if you constantly offer each other feedback.
With constant feedback you might start to notice more more light bulbs turning on in your teams heads. It's no use if only you can see why a certain piece of code smells, but the rest of the team needs to see it to.
Most developers try to put out the best possible code that they can. They want to deliver value, so if you spot a better way that someone can do that, show them. It's the code that sucks, not the author.
The Office vs. The Studio
Saturday, November 24, 2007 10:20:24 AM (Mountain Standard Time, UTC-07:00)
On my bus ride home yesterday, I was trying to think about what separates our office from others and I realized it was that our office was less like an office and more like a design studio.
A studio celebrates discussion and creative thinking. It challenges you to think creatively and outside the box. Your uniqueness is what makes your product a better option than your competitors.
I asked my wife what she pictures when she thinks of a designers studio. Here's some of the things that she said:
- Open style loft
- A New York style high rise building with lots of windows over looking a park or people walking along the street.
- Boards on the wall covered with peoples ideas.
- No cubicles
- Elevated desks, like the ones architects use that are tilted sideways and are high enough to look outside.
- One long table where people can come together.
My picture of a designers studio is quite similar, except I see white boards scattered just about every where. So you can have an impromptu design session while eating lunch, where you can literally stand up and start writing on the wall. I picture an open work space, where people can actually see each other work. I picture constant communication and feedback.
When I think of an office, I picture cubicles where people spend their days isolated at their desk. I picture a lot of emails being read and answered. I picture a lot of phone calls being answered, and less face time with people. The office is usually quiet, so if you want to have a discussion you've got to send a meeting request through outlook and book a board room to communicate with others.
Why is that when we think of where software developers work its in an office and not in a studio. Designing software is a lot like designing art. It takes a lot of creativity to build code bases that not only deliver clients value but also make other developers want to contribute to the code base.
In my opinion, if you are striving to create an Agile shop, start by trying to create a studio environment and leave the office behind.
Abject-Oriented Programming
Monday, June 18, 2007 11:49:47 AM (Mountain Standard Time, UTC-07:00)
I just read an excellent article on Abject-Oriented programming. A new way of programming, derived from Object-Oriented programming. I highly suggest that everyone read this post. here...
"A good time to write documentation is when someone in the department gives two-weeks notice: use that time to make sure the departing team member documents all of their code."
The Art of Software Estimatation
Wednesday, May 09, 2007 11:29:47 AM (Mountain Standard Time, UTC-07:00)
So Mr. Scott Hanselman just recently posted an article about Software Estimation. In the first comment on the post there was a link to an article on MSDN that I thought was also interesting, titled "From Bouncy Balls to Better Estimates".
Estimating how long is going to take to build a piece of software, is definitely one of those touchy questions. Early in my career, I remember when my manager would ask me how long it would take to build a new feature into our product. I would do my best to please him with my S.W.A.G., and then afterwards I would do my best to make sure I was on schedule for delivery... it's interesting how that silly acronym (Silly Wild Ass Guess), was a nice way of saying...
"Hey mO, can you tell me that you can build this feature into the product in less than a week? So that I can go tell that client that I wasn't lieing and that we actually have that piece of functionality already in our product!"
Oh man... this brings back to many bad memories! I'm not as eager to please others, especially sales people. It is possible to deliver some pieces of software in almost no time... but you're probably going to put out a pretty bad product. I have recently caught the TDD, or BDD bug. I'm very rigid, and feel rather uncomfortable delivering a piece of software that I don't feel confident in. By having Unit tests to back up my code, I have that extra level of confidence...
So when someone comes to me and asks me how long it will take to build this... (read below) What am I supposed to say?
System Features
- Windows Forms-based interface programmed using C#.
- Simple, large button interface.
- Ability to print 4" x 1.25" tags
- One (1) web report using MSSQL Reporting Services
I'm not even sure where to begin... what am I supposed to build? And you want an estimate right away? You told the client that it would be done yesterday? Uhhh.... great, so basically anything that comes out of my mouth means nothing!
Good day... I said GOOD DAY!