Secret Perl Operators
Yet another mailing list I’m on is Peteris Krumins’ blog, good coders code, great reuse. He posts about software development, hacking, security, code reuse, etc. This post is on advanced use of obscure Perl operators.
Python Creator Makes Brave Move
According to this article (and others), Python creator and BDFL (“Benevolent Dictator For Life”) Guido van Rossum froze the Python language’s syntax and grammar in their current form for the the next few releases, and possibly longer. The reasons are good ones; To let developers catch up to the latest release, to let the rich array of third-party tools stabilize, and to improve the quality of the existing libraries. I think it’s a bold move, but the right move.
Favorite StackOverflow Threads
I’ve mentioned StackOverflow before. It’s a place you can ask and answer questions about software development. It’s got a strong reputation system that keeps the nut jobs and spammers at bay, and I’ve found it very useful. Not all the posts are about slaving away over a hot keyboard, though.
Server-Site Web: Java Vs PHP
I had a conversation the other day with a fellow Software Engineer about a web-based project I want to start. There are several advantages of these two technologies, and clearly either one would be sufficient to do the job. As a Software Engineer who is constantly striving to improve and up my skillset, I also have to think about what technologies are going to further my career. Developers, I would love to get a discussion going on this topic, so please leave comments. Oh, and I am purposely sticking to these technologies because I believe strongly in cross-platform tools, and these are the two top contenders in that arena. And we’re talking server-side options. So no whining from the .NET/Flex crowd.
Scrum and Scrum Roles
I fell upon this article on the Methods & Tools website, a free software development magazine on software development and software engineering. The author is Anna Forss. She lives in Sweden, and her English is not perfect, but the article’s content is so strong, it’s worth the read. I recommend this article to anyone who wants to get a feel for what Scrum is, especially if you’re not a Software person.
The article starts out with an overview of the heart of Scrum, and how it doesn’t tell you how to develop your software per se. It tells you how to organize and communicate, but it doesn’t cover anything like unit testing or pair programming. You can combine Scrum with other practices effectively.
The main part of the article is about the roles people play in Scrum, in particular the Product Owner and the Scrum Master. Anna is a Product Owner (she doesn’t do any Software Engineering herself), and this part of the article implores the non-Software people in Scrum-using companies to take the time to learn it better, so they can be more effective in interfacing with the developers. Since I travel mostly with other Software Engineers, I hadn’t really heard about Scrum from the other side very much, and she makes a strong case for selecting the people to fill these two roles very carefully. A good Scrum team can get by with an OK Scrum Master, but a Product Owner that doesn’t do their job right will surely kill a project. She also addresses why the two roles shouldn’t be filled by the same people.
Anna Forss has a blog here (I almost want to publish some articles as RDF Triples). Her own blog has some great posts, like this one on The Business Value Of Boring Stuff and What Can We Learn From Coffee?. She’s also the author of Confessions of a Serial Product Owner. My only complaint is that her blog is on Windows Live, and I’ll be damned if I’m going to get a Windows Live ID so I can post comments on her blog or subscribe to it.
Don’t Like Pair Programming? How About Co-Programming?
One of the many ways in which I am weird is that I love pair programming (two Software Engineers working together on the same computer). I’m a social animal, and I have the self-confidence to appreciate corrections couched as constructive criticism. But many Software engineers hate it because they feel they’re being judged constantly. And of course a lot of Software Engineers are introverts or have poor social skills. Or just like a little breathing room.
At my last company, I was instrumental at rolling out Agile on selected projects (because I believe in using the right tools for the job, and because Agile was not right for every project). My current employer, alas, is nowhere near ready for Agile. We’re trying to make some major changes to a product that affect the Flex front end, the Java back end, the XML and XSLT documents that hold and transform some of the data, and the databases. All those components need to dance together, or someone’s toes are going to get stepped on. But there’s no one person with all those skills, and certainly not enough time for one resource to do it all.
So here’s what we’ve been doing; My partner in crime (let’s call him E. He hates that.) and I are working physically side by side, but not together on the same thing. While E’s flexing the Flex and pouring the Java it talks to, I’m torturing the data till it sings, and pouring the Java that manages the data. But when either of us has a question on how something should be working (E may have questions about what’s in the data to help determine the expected results, or I may have questions on how a particular query is formed or the results processed), we’re right there to point at things on our screen. The fact that we’re working on two different computers isn’t a problem because we’re both syncing regularly with the version control system.
Clearly this is not pair programming, because we’re both working on different things most of the time. But there’s something different going on than if we were both sitting in our own desks. The barriers to communication are very low, and we can point out stuff right on our screens because they are next to each other. It’s a great balance of supporting each other while still doing our own thing. I don’t know if there’s a real name for what we were doing, so I decided to call it Co-Programming.