The Human Aspect Of Software Engineering

As a computer scientist/software engineer, it's easy to forget about the human aspect of what we do. We are often so immersed in very technical parts of the software that we forget that everything we do is for a human. If we don't keep that human in mind, the product really suffers. No matter how technologically innovative a piece of software might be, if there isn't a real, useful human connection, the software will ultimately fail. In that sense, considering the human aspect is the most important aspect to consider when writing software.

Modern development treads seem to be making steps to consider end users more during the development process. For example, agile development stresses getting early involvement from users, to ensure that the human aspect of software is always addressed. They also encourage frequent updates and demos to customers to ensure that they are always satisfied by the product.

I suspect that a lot of usability issues stem from not considering the squishy thing between the chair and monitor. Most of user interface work seems to be figuring out the best way to create that connection between the cool techy thing the developers did and the human using it.

It's easy to forget that most people are not very technologically savvy. You'd be surprised at the amount of people who don't know that you can right click. I think it's really cool that Interpolation search is O(log(log(n)).. Most people, however, don't care about this at all. They do care about reducing their search time in your software though.

It's important to always keep this human aspect of software engineering in the back of your head at all times. It can really improve the software you produce.

Why Agile Development is More Fun

I just read this article claiming that Agile is "boring". I'm not sure how this person got to that conclusion. He also claims that Agile is very rigid and strict, although it's probably one of the most relaxed project management methodologies out there. It's certainly more dynamic and flexible than Waterfall models are.

From the article, it seems that this person works somewhere where they don't have any concept of project management at all. He talks as if he doesn't have deadlines to meet for his organization. Not sure where he's working where he can get away with this. Almost all projects have deadlines. It's very useful for business people to know things like estimates and set deadlines. Pretending they don't exist is no way to professionally develop software. Certainly not a realistic way to grow as an organization.

The writer says that Agile development gets boring after you do it for a couple projects. Not sure where that's coming from. I find that Agile development environments are much more interesting, because there is much less repetition. From iteration to iteration, you could be working on very different projects. Agile allows (and even encourages!) developers to explore other areas of the software and cross-train. You are also much less likely to be pegged as the "Database guy" or "UI guy" in an Agile project. While you might have a lot of experience with UI, your task is really whatever the project needs. If that means moving outside of your domain, so be it.

When I worked at Karos Health we practiced Scrum, a form of Agile, and I found it to be very flexible. While most of the time I was developing UI code, I also participated in all the other sections of the applications. I got to see all the parts of the application.

Also, Agile teams are encouraged to work very closely together. This interaction creates a very interesting working environment where you are constantly learning. This is certainly more interesting than working your way down an ad-hoc todo list by yourself, conversing with other developers only when absolutely necessary.

I suspect that the author has never worked in an Agile company (or at least one that's practicing Agile correctly), because his comments seem to be the opposite of what Agile development encourages.

TDD and YAGNI

Here's an interesting read. It talks about how if you practice Test Driven Development (TDD) in an Agile environment, there is a lot of pressure to adhere to YAGNI. YAGNI stands for "you ain't gonna need it". Developers often try to predict what features the code might need in the future, and try to build it in right away.

The problem is that most of the time, you won't actually need that feature that you predicted you would.  To avoid this problem, supporters of YAGNI try to write the smallest amount of code possible to accomplish something. TDD has a similar belief in that they stress writing the smallest amount of code possible to satisfy a test.

This seems like an extreme to me. While I agree that future proofing every part of your application is a silly idea, I don't think that this sort of TDD and YAGNI is very scalable. It's not really about doing the simplest thing possible, it's about the simplest thing possible that doesn't code you into a corner. You want to make reasonable assumptions about what will change, and future proof that. It's important to be pretty conservative with your guesses here, though.

A good developer will be able to draw on past experiences to predict that some things will happen. If they think it's easier to build it in now, they should. I would trust the judgement of an experienced developer over a best practice.

I feel like YAGNI is overcompensating for developers who apply design patterns to everything ever because they learned to do that in school. This is obviously the other extreme.

It's like software development practices are following a pendulum, going for extreme(Waterfall, design patterns everywhere) to extreme(Extreme Programming, YANGI). It's still a very volatile field because it's so young. Hopefully the industry will settle down somewhere in the middle.

New York!

I went to Sackets, New York with Dani this long weekend! I got to go to my very first wedding! It was so much fun!

I had scrum training with Declan Whelan as part of REAP on Friday. It ended at 7pm, so we had to leave pretty late to New York. The training was great! I'm very interested in seeing how the REAP team can apply Scrum, and it's concepts, to a non-software project. The whole team seemed to be very interested in pursing the idea of using Scrum for the project, so we'll probably get more training in the future. Awesome!

Anyway, we left Waterloo pretty late. We stopped by Toronto to get my passport (border laws >_<), and then chugged along to our hotel in Watertown, NY. We got there around 1:30am. I learned (slash remembered) that King sized beds are not a little bigger than a Queen sized bed. They are much, much bigger. It was awesome. Of course the first thing we did was jump on the bed. Go us.

Next morning, we went to the wedding in Sackets. They had a small (40 people) ceremony under a gazebo overlooking the harbor. It was quite pretty! The whole thing only lasted about 10 minutes. A good introduction to weddings for me. :P

After that, Dani and I sneaked off to eat some food, while everyone else took buttloads of pictures. It was good.  Then we went to the reception...somewhere. lol. That was also fun. We actually got a chance to talk with the bride and groom. It was nice of them to take time to talk to all the guests. :)

After the wedding, we were both exhausted, so we went back to the hotel to relax. Dani fell asleep for 2 hours and then couldn't get to bed until 5am. Sweet deal.

Sunday was mostly uneventful. In the morning (well, "morning" = noon), we went for a drive around Sackets. It's a really nice city. It reminds me of cottage country. It's fun to see how american flags there are in that city. Literally every pole has a flag on it. You never see that in Canada.

After our morning joy ride, we went back to the hotel, watched a movie (My Big Fat Greek Wedding!), and then went on another late night joy ride! We went on a quest to find an open Dunkin' Dodo's (tm). We got lost. Surprise. It was another fun drive though.

All in all, it was a great weekend. My first wedding was excellent! Yay! :)

Release Early, Release Often...Carefully

There's a lot of talk about the idea of releasing software early and often. The idea is that you get software out to your users faster, so you can get their feedback faster. Releasing software often also has the benefit of keeping your users constantly involved in the development of the application. In general, "Release early, release often" is a great idea... if you do it well.

The caveat is that people need to be really careful with what they release. It is okay to release a new version of your software with just one new feature. Releases lacking features are fine. Quality, on the other hand, should never be compromised. That is, you should never release untested software or software with major known problems. You should never think "That's okay, we'll just fix the bugs in the next release. We release often anyways". I find this incredibly annoying behaviour from software companies. Not only is it very frustrating, but it also makes me question the professionalism of the company. Releasing untested programs is never acceptable. It makes a very negative impact on the user's view on the company's stance on application quality. Users understand when your program is still in it's infancy and is missing features, but they shouldn't have to deal with bug-filled applications.

Keep that in mind when you are considering a release of your software. Quality should never be something that is put off for a later release.

Importance of Data Visualization In Agile Teams

I went to an Agile P2P meeting after work today. The speaker was Jason Little, an agile coach. He seems like a very interesting guy. I like how he doesn't seem to get bogged down by what "agile" says you should do, but rather he focuses on getting actual results. It's refreshing to see.

Anyway, he was talking about the importance of data visualization in agile teams. By displaying data in concise and intelligent ways, major problems become much more evident. Problems that are hidden by poor data presentation can become glaringly obvious when you display the information in the "right" way. Uncovering these problems is a huge part of improving what you do as an organization. For example, take stories in your electronic issue tracker. If you have a lot of bugs in your issue tracker, you might not see it right away because of the way they're organized. If instead you put all your issues on coloured sticky notes on a board, and you see a clump of red tickets, it becomes immediately obvious that your software development process might have serious quality gaps. If you further organize those tickets by time, you can visually see when a lot of those bugs were discovered (and can guess when they were introduced).

The importance of data visualizations doesn't only apply to agile though. Data visualization is important in a lot of fields. Humans suck at looking a unorganized data and making sense of it. Computers are much better at this. Data visualization will be very important in the future to help humans make sense of the immense amount of knowledge available in some fields. Like in the agile example above, some problems might become glaringly obvious if you organize and display the information in the "correct" way. The cure to cancer might be hiding in the data, and it's just a matter of showing it the right way before it jumps out to someone.

Okay. I'll stop procrastinating now and finish off that work report.....



....



or watch Community.

A Lot To Learn

Today at Karos Health, we had a retrospection with Declan Whelan, an Agile coach in the Waterloo area. I thought that it was very interesting. I came out feeling like I still have so much to learn about this industry. I pretty much feel this way every couple months. :P It's a weird feeling. I think I'll come out of university feeling much stupider than I felt when I came in. I guess having an awareness of what you need to learn is pretty important though.

So here's a list of things I would like to work on; my personal improvement backlog. :P Priority to be determined.

- Test Driven Development. I feel like won't really understand it until I actually spend a few weeks doing that. I am still unconvinced of it's benefits, but I think the best way to really decide its effectiveness is to actually practice it.

- Pair Programming. I've already done a little bit of this at work and for school projects, but I think the cross-training that it provides is really useful, and I'd love to try it for longer periods of time.

- Language Expertise. I still want to learn some language really really well. I think C# is a good candidate for this. It's still my favorite language.

- Technical Expertise. There's just so many technical things I don't know about. How do you do secure network communication? How can you ensure high availability? How can you efficiently do *? What standard libraries exist for doing *? I would like to know so much more about these topics.

- Agile. All my agile knowledge comes from many different informal sources. I think I should try to learn it more formally by reading through a book, or taking a course or something. There are a lot of fundamental things that I'm still trying to figure out, and I think that formal training would be very useful.

- Healthcare. There's so much to learn about the being a developer for the healthcare industry. There's various protocols: HL7, DICOM, and frameworks for working with them like XDS. I know very little about how these protocols work. I know even less about the interoperability problems that arise from having many different protocols.

This list is a little overwhelming. I don't know where to start. Instead of doing a "breadth-first search" into these topics like I have in the past, I'd like to dive into one of them and get to know them very very well. Too bad I'll have Real-Time next semester. :/ I guess I'll make time after that. :/

Swarming!

Our project manager at Karos Health shared a link with us the other day about Swarming.

This is the first time I've heard of this technique and it sounds quite interesting. The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done.

I also think having many developers focused on a single story encourages collaboration and teamwork. It forces everyone to work together very closely, and this probably leads to getting the story done faster.

Of course, the story in question needs to be big enough to allow multiple developers to work on it together without stepping on each other's toes. If our J3WAO stories weren't so small, I think it would be interesting to try it there.

Product Sashimi

Yesterday, I had a chance to go to my first Agile P2P meeting. The talk was on Product Sashimi, and how to "slice a thin product" by J.B. Rainsberger. The main point Rainsberger was making was that there are benefits to be had by breaking up a large project into several smaller projects.

He started by defining 3 values of software. The first is features. This is what most business people refer to when they talk about business value. The second value of software is design. If a piece of software is poorly designed, the cost to add features to the system increases very quickly. Eventually, the cost of adding new features surpasses the cost to simply rewrite the software from scratch! Rainsberger affectionately refers to this as "Product heat death". I lol'd. The third, and main value Rainsberger talked about was how long before a customer can say "not what I wanted".

The sooner we get to that point, the sooner we know that the project is off track. He also mentioned the 80/20 rule for software features. Essentially, 80% of users will only use 20% of the features. The version that he stated was that only 20% of your features will be used often. The other 80% will be used rarely. 

Rainsberger says that if you "slice" thin products, you are more likely to get to the "not what I wanted" stage sooner. If you get to the "not what I want" stage sooner, you can catch those 80% less useful features earlier, and redirect your developers to the other 20%. Now this isn't to say that those 80% aren't important, but it does mean that you shouldn't put as much priority and emphasis on them.

He went over a few interesting techniques for breaking a product up into independent project regions. He also talked about how important it is to skin use-cases/examples into the simplest versions possible. Usually this involves reasonable (and sometimes unreasonable) sacrifices in usability. These simplifications let you skin stories into their simplest versions. The extra usability features can be added in later, once they're prioritized by the software users. They key is to get a full, working piece of software out to the users so they can tell you that you did it wrong. Although the software might be short on features, it covers the full breadth of the project. I thought this was one of the most useful things I learned that night. I definitely think we could have applied these techniques to j3wao, but I'm sure we will in the future.

In general, it was a great first Agile P2P. I'll be sure to be involved in more of these sorts of events in the future. In particular, uxWaterloo sounds quite interesting. I am really glad I discovered these community events. :)

Also, 528