Archives

Do you know every detail in the Flex framework by heart? Do you also know all the other libraries that you use by heart? Well I don’t and I often have to reference some online resource while developing.

For instance, I always have Action Script Language Reference, Wikipedia, some library API site(s), Gmail and a dozen other ones open + the debug version of the app at hand.

So what used to happen when you but a breakpoint in Flex Builder with all these tabs? They would be unavailable and any process happening inside of them could not be relied on. Since not all code runs well on first attempt, if the app crashed while testing ( think 3D, data intensive apps, etc.) the browser and all the tabs went down with it.

My solution so far was to use Firefox as a development browser and Safari ( since I’m Mac based ) as a browser for references and everything else. For crashing resolution, Firefox has a nice “Restore” option but it’s not fun waiting for 15 tabs to reload.

So Google Chrome recently came out for Mac. It didn’t impress me on Vista so I didn’t care much. I guess I was in between of curious and bored so I decided to give it a spin.

What a pleasant surprise to see every tab running in a different process. My workflow feels so much better now that I’m not afraid that a bad line of code is going to take down my whole browser.

I’ve heard that IE8 also runs tabs as different processes but I’m not crazy about returning to development on Windows. I did try out Chrome on Windows 7 as a result of the Mac test and all the issues I’ve seen the first time around have been addressed. Kudos to Chrome development team.

Let’s not forget to mention all the features that are missing on Google Chrome for Mac, primarily the lack of Bookmark Management, but Google Bookmarks or any online bookmarking service will do for now.

I can not wait to see more development being done on Google Chrome for Mac and it getting out of beta. I will not uninstall Firefox anytime soon but as a Flex developer I give Google Chrome for Mac high scores for beta.

Share/Bookmark

So we just went through this humongous (believe me!) effort of upgrading the technical platform for one of our existing Rails applications that was running Rails 2.1, Ruby 1.7 and Mongrel cluster. The goal was to upgrade to Rails 2.3, Enterprise Ruby 1.8.6 and Passenger. It all started out as well as you would think. Updating the Rails gem, Ruby version, installing/configuring Passenger and updating relevant gems was pretty quick and smooth. Some quick and dirty testing of the application did not reveal any major problems or issues. Great! You are thinking the upgrade is mostly done att this point before you move on to the tests in the application!

Tests

Tests can prove to be major hurdle in upgrading Rails applications.  In our specific case,  close to 70% of the tests were either broken or failing due to a number of reasons.  Actually, the number of broken tests was way way greater than failing tests which led us to think the changes in the Rails testing API caused most of these issues.  Some of the issues were also caused by a plugin or gem that was used to support the tests not being compatible with the new API. It took us quite a bit of effort to figure out the reasons for the issues and also find the fixes.

Share/Bookmark

photo credit: °Florian

Yes, Cloud Foundry has been acquired by Spring Source and seems to be morphing into a for-pay service, and there hasn’t been a new build packaged on the Cloud Tools project page since January of 2009, but if you dig in the SVN repo, you see there’s a bit of activity. Before I try building from source, I wanted to see how hard it would be to get 0.6 Grails plugin working with a Grails 1.1.1 app.

Well, harder than I thought. There’s a real lack of documentation around cloudtools for one, and the radio silence on the project page over the last few months hasn’t helped. Fortunately, Don over at AlterThought has put together a nice post that covers most of the pitfalls and problems with the CloudTools Grails Plugin. A few things they don’t address and I thought I’d throw in here:

Share/Bookmark

Twas the night before Christmas, and 500 pages of detailed requirements had been produced. No line of code had been written, not even by a mouse.

It sounds great in theory: You produce requirements up front, getting them so detailed that they cannot be misunderstood, you vet them with a full committee of stakeholders who will be impacted (except your customers.) Then you give it to the developes. The result: you can get a really precise cost and timeline, you’ll save on expensive development time, and your CFO will sleep soundly at night.

It’s a nice fantasy, but it’s wrong. It’s a fundamental misinterpretation of how software development works. In fact, it’s a guaranteed way of increasing your costs and producing bad software.

Here’s why:
If you’re developing software, you’re coming up with a new solution to a problem, or solving a new problem all together. Otherwise, why are you building software, rather than buying it?

Traditional requirements definition processes are a spectacularly bad way of understanding stakeholder needs, and coming up with, conveying and vetting a solution for these types of problems. You will miss certain requirements, you will over specify others, and some of them will never get used. Your stakeholders will only be able to provide feedback of limited value until the working software is actually in their hands. At that point, you will finally start getting valuable feedback that you can push through as change orders.

Share/Bookmark

With apologies to Dave Eggers, this post is not about traveling around the world in a week to give away $32,000, but about measurement and agile development.

One objection to agile development we get sometimes from people who have never done agile is that it sounds too undisciplined, unstructured and risky.

Would they say the same thing about lean manufacturing or six sigma?

They’re confusing agile with cowboy coding.

In fact, like six sigma, agile software development is explicitly about reducing risk, measuring efficiency and continuous improvement.

The old management adage of “You can’t manage what you don’t measure” holds true in software development as well. If you have no feedback loops, and you’re not measuring and improving, you’re not really doing agile development.

The core measurements we use are story points and velocity.

Share/Bookmark

Too often in software development projects, we’re asked to provide what I would call thoughtless reports. By this I mean a collection of tables and charts that depict and enumerate standard relationships. There’s nothing wrong with the reports themselves, mind you — we know how to present relationships in graphical form. No, the problem is that no one has given much thought to the relationships that are being depicted.

You’ve probably heard about the finding that in children, shoe sizes and handwriting quality are highly correlated. It would be wrong to conclude, however, that one causes the other. In fact, as children mature, their shoe size increases, as does their cognitive ability and their motor skills. They are all dependent on age.

Share/Bookmark

photo credit: belgianchocolate

In my last post about innovation I referred to Clayton Christensen and his concepts of sustaining versus disruptive innovation. It reminded me a little bit of the concept of punctuated equilibrium in evolution.

The idea is simple: suppose you have a bunch of monkeys working in an office. You have the executive monkeys who eat healthy meals and exercise at lunch time. Then you have the office drone monkeys who go outside into the rain and cold for smoke breaks and eat gyros and fries for breakfast. The executive monkeys have nice glossy coats, get the best mates and have nice condos in desirable parts of town. The drone monkeys…not so much.

Share/Bookmark

Theresa Neil over at InsiderRIA has a nice post about 28 data visualization tools. You could google these yourself, but she’s actually put together a bunch of screen shots and collected them all in one place.

If we’re honest about it, these aren’t really “data visualization” tools. They’re some decent graphing and charting libraries. Data visualization is more than just pretty pictures. Providing the user with direct manipulations and other interactions is also a key ingredient to making the data understandable to system users. As such, these 28 tools only provide one piece of the puzzle.

Share/Bookmark

By now almost everyone has figured out that traditional fixed bid doesn’t work for software development projects, especially where effective, intuitive user interaction is a significant component of success.  Over time there has been a lot of effort devoted to finding the underlying reasons for project failure.  The Standish Group Chaos Report for 2002 found that 45% of features developed were never used, their 2008 Chaos Report found that typical software projects come in at 189% of original estimates (there is an obvious correlation there), and many studies over the years have concluded that an uncomfortably small percentage of development projects are viewed as meeting or exceeding expectations or providing competitive advantage.

Hidden implications of “fixed bid”

Although you need to provide a target budget to get projects approved, “fixed bid” for application development starts of with a faulty basic assumption – that user, functional and system requirements are fully known and documented in a way that enables efficient development. True fixed bid also implies “waterfall” development and two assumptions: 1.) you have completed a thorough, efficient design phase, and 2.) requirements won’t change during the development process. Neither of these assumptions are realistic.

Share/Bookmark

photo credit: sanchom

In some past posts I’ve looked at some of the cultural, organizational and process issues on why large companies find it hard to innovate with new, quality software. Today I want to take that process a step further and look at why established players have such a hard time innovating in general.

First two anecdotes, where I will combine the topics of Susan Boyle, chess and the Kindle. First, chess and the Kindle.

So I now am the proud owner of two Kindles, the small format Kindle 2 and the large format DX. It’s great for reading novels, less so for reading reference books where you jump around a lot (even setting and using bookmarks in a small 30 page PDF is a pain). There are two areas where the Kindle falls short: there are very few chess books for it and there are even fever German language books. Hopefully that will change with the advent of the international Kindles and soon amazon.de will start selling ebooks.

Share/Bookmark