Generally speaking, I hate frameworks. Most frameworks I’ve met fall into one or more of these camps:
- Frameworks so lightweight that they’re not worth the hassle of using them. These frameworks can be useful when you need some functionality that you don’t want to learn in detail how to do. This is almost never the case for me, because I like fully understanding any technologies I rely upon. That’s why at Aptima I wrote my own AJAX JavaScript library. It was something like 50 lines of code, worked flawlessly, and worked exactly as I wanted it to.
- Frameworks so heavy the work to utilize them approaches the work of rolling your own. This often happens with frameworks that start out simple and are expanded to encompass too much functionality outside of the original scope.
- Frameworks that are staunchly inflexible in how they are used and how they work. Using a software tool to make your life easier should not like implementing an ERP system. This often happens when when the framework was designed for a specific purpose then released as a separate product. See The Cathedral And The Bazaar.
- Frameworks that are completely opaque or have an unreasonable learning curve. Most meaningful operations in software have some sort of side effect you need to be aware of. Insufficient documentation and software that does not follow the mantra of the Principle Of Least Astonishment can make diagnosing problems a nightmare.
I’m currently working on my knowledge and skills with Spring and Hibernate. They continue to fail to suck. I was very surprised how easy they were to implement, how much they’re for me, and how flexible they are. Spring is a framework that specializes in (among other things) inversion of control to promote decoupling and testability, and Hibernate is an object relationship mapper that eases the burden of persisting entities in a database. There are many good tutorials on the Intertubes, but I’ve been working my way through the book Spring Recipes, which covers both technologies very well.
Read on…
Some think Agile is all seat-of-your-pants. That’s not true at all. Agile requires knowing where you are right now and what you need to do in the near future; it just doesn’t put a lot of faith in guesses where you’ll be 8 months from now.
The various forms of Agile all contain a set of practices to follow and others to stay away from, each with their strengths and weaknesses. Successful implementation of Agile requires selecting and implementing practices that complement and support each other, covering all required needs without duplication (which is where a good deal of the efficiency comes in). It’s bad enough if you pick a set of practices that don’t support each other, but it’s much worse to chose the right practices but not implement them right. That’s because it can create a false sense of security. Read on…
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.
There is a mysterious underground Perl organization that hardly anyone has heard of. Their primary mission is to discover new secret Perl operators but they are not allowed to talk about them. I managed to infiltrate this organization and steal some of their secrets. Here are 8 secret Perl operators that I retrieved from their mysterious hoard.
This is a great (and entertaining) article. However, it exposes the thing that I like the least about Perl; its reliance on punctuation marks to greatly change the meaning of a block of code, and the ability to replace a perfectly good explicit code block with a few squiggles and variable names to show how clever the developer is. The trouble is, this cleverness make the code much harder to understand by the next person that needs to work with it. These days, 9 times out of 10, code legibility and malleability will benefit a company much more than brevity.
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.
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.
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.
Read on…
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.
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.
Title: Ken Schwaber on “Flaccid Scrum – A New Pandemic?”
When: Thursday, 06/18/09 06:00 PM – 09:00 PM
Where: MIT Building 26, Room 100, Cambridge, MA – Cambridge
Cost: Free
Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.
Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.
Ok, that sounds like like a pretty obscure line. But that’s kinda the point. This article from Agile Observations from the Trenches blog. Yeah, it’s an article about Agile software development. But it’s really about accomplishing any goal.
It’s really worth reading the article, but here’s what that title is about: Sometimes you need to accomplish task Foo, but then you realize you first need to accomplish task Bar, and then before Bar you need to do task Baz, and so on. It’s easy to lose sight of the original goal, and then you’re really in trouble.