Some Python Nuances

Me and my partner have been struggling a little bit with the current project due to some misunderstood Python nuances. Our current implementation to the Project File Dependencies problem on Sphere calls for a list of lists. Seems like standard procedure right? We should just use Python's overloaded * operator to initialize the data structure like so:

matrix_size = 5 
matrix = [[]] * matrix_size

Which, if we print out the matrix, we get the following output:


[[], [], [], [], []]

It seems like it is working just fine, but if we do a simple operation, like add a number to the list at index 0, funny things start to happen. See the following operation:

matrix[0].append("?")

and the contents of the matrix afterwards:

[['?'], ['?'], ['?'], ['?'], ['?']]

How does this make sense? What were the creators of Python thinking? Why does this functionality make sense? I do not understand why this is the case. It is acting like each list in the matrix is just a reference to one matrix. In order to get the functionality we wanted we had to do something like the following:

matrix = [[] for i in range(matrix_size)]

which seems to be working just fine because a new list is created for each index.

Another issue we were having lies in the annoyance that Python has no increment or decrement operators! And if you try to use them, nothing happens! It is valid Python syntax!

It is all ok though. With every new language comes a little bit of headache. As far as interpreted languages go, Python is coming to be one of my favorites so far, and as long as I can minimize future headaches like the first one in this post I think I will be quite alright.

Write Tests Before Development

In my recent programming travels at work I have come across an increasing problem: Communicating the importance of testing to the project manager. Sometimes, oddly enough, the manager does not allocate time for testing in the development cycle, and simply accepts a spike solution as the final solution and asks for more features.

To a project group not accustomed to the methods of Extreme Programming, how does one communicate the effectiveness of the programming methodology to his or her peers? In my opinion it is simple, you just do it anyway.

Sure, the manager might moan about how it is taking you a little longer to get things "complete", but the difference is code that "somewhat provably works in all possible cases" versus code that "works in a small demo and might work in more cases". Writing tests first makes sense for a variety of reasons. First, it allows you to define the exact purpose of a method or function by testing different inputs on defined outputs. Every time I change or refactor some code in a class, I don't want to have to open up the GUI and click through different execution paths just to test some small method. Writing the tests first also allows you to double check a story with the "customer" who created the story (In my case the manager) and make sure the expected output is really what is expected. My final reason for writing the tests first is that you won't be tempted into not writing them later. A lot of times when we write code and build on it we can get the illusion that the building block classes that make up the outer level tested class work correctly, which might not necessarily be the case. If someone writes another api or class that utilizes an untested class, it opens up the door for new execution paths which can introduce new bugs.

Always test your code. Test first, and your life will be much easier later on in the development cycle. I can't stress it enough!

Stories in Extreme Programming

It is just recently that I have been introduced into the world of Extreme Programming. Once I was exposed during the Spring semester in Dr. Downing's Object-Oriented Programming class, and now I am really getting to dig deep into what it really means. During the first 8 chapters of Extreme Programming Installed the authors stressed the concept of stories, which are quite literally index cards on which the customer describes the function of small pieces of a focal application, and possibly some implementation.

In my current internship with ARM, this concept has been extremely helpful in encouraging complete and thorough communication between me and the customer, which is actually the "project manager". Basically a two man team, I write all code-related things and he simply communicates what he wants to happen on my whiteboard. He knows exactly what he wants the application to do. He is not a software developer (that's my job!), but it is up to me to interpret the functionality he desires and portray it in the most effective and scale-able  way possible. Everyday, it is a conglomeration of new stories on the whiteboard. Some are trashed, some rewritten, some split up into different stories, and some finished.

I understand it is not quite a stack of index cards like the book suggests, but the idea remains the same. I am not necessarily a hardware guy, and I often struggle with understanding why things need to be done in according to how the story is written, but because my manager so effectively communicated it in the story, I am able to develop and make him and the other users of the software happy.

When I first read the assigned chapters, I found it interesting that I had already been writing stories unknowingly all along. I have also found that when you, the developer, start writing the stories instead of the consumer, things can get hairy fast. You might think you know what the customer/consumer wants, and while you think you know, you'll soon find that stories which are already implemented may have to be trashed pretty quickly. This is why it is important to keep your customers close. Have them right the stories, and development will happen very quickly, or as quick as you say it will.

Happy story-writing!

A New Beginning

Hello fellow pupils and random internet surfers, my name is Cole Stewart. I am a computer science student at the University of Texas at Austin. I took Object Oriented Programming in the Fall from Dr. Downing, and I am very excited to see what Software Engineering has to offer.

This week we talked about the first project, the Collatz Conjecture, which basically states that when given a number, if it is even, divide it by 2, and if odd, multiply by 3 and add 1. When applied repeatedly to a number, it will eventually reach 1. It is an interesting conjecture as nobody has ever actually proved it, but a counterexample has never been produced.

All in all, I am very excited about this class. I am currently working at ARM and use topics learned from Object-Oriented Programming everyday. I am a Java Swing developer, and the class really allowed me to better understand how objects communicate with one another. I am really looking forward to learning more about Python and Javascript. They are things I have always wanted to know more about, but never really had the willpower to do so. This is going to be a great semester.