16 Nov

The Decline and Fall of Agile

A good writeup by James Shore on The Decline and Fall of Agile (James Shore blog).

Software development projects are a hard thing; not necessarily because of the software, but because people are involved.

I’ve worked on the most mature (and rigid) software development process in the world, the Space Shuttle on-board software (SEI 5), and on places where no process existed (startups). And I can safely say that because not all teams and projects are created equal, not all process should be equal. I’m not religious about any specific type of process. The best process is the one that is/can be followed. The best process is the one that works for your team/people. Processes can’t be forced-fed onto developers, Agile or not. Changing or implementing development processes can kill a project, especially if it impacts the existing “culture”. It is smart to consider a phased approach to this, for example, start by exploring/adapting some of the new concepts to current projects, vs. totally diving into it and potentially putting the project in jeopardy. Know to be flexible when implementing projects and when to stop pushing for (defer) something; developers (and anyone) can easily get distracted with process-things vs. delivering a product. Time is of essence, go-to-market your first priority. Processes are overhead.

Regardless of the process used, it is about minimizing the unknowns, and this is accomplished via proper planning (as needed for the phase of the project) and visibility, and execution and control, from charter to go-to-market.

Processes are at times, OK, most of the times, rejected by developers, mainly if forced, and especially if forced at the wrong time; note: developers are not stupid and what they want is to be given clear and achievable instructions (requirements) and to build and deliver it on a reasonable time-frame. Realize that process-wise sometimes most of the times “good enough” is OK, as long as things are delivered on time and with good quality. Be flexible and use what works for you; processes like Scrum or other are really guidelines.

I like to have initial efforts at front. I like to have initial planning that allows for “good enough estimates” on time-frames and budgets early on, and then I like to go iterative with cycles or sprints that allows for quick visibility and adjustments as needed, adapting in length based on where we are in the project, and team’s needs. Same on the design, I like to have an initial take at the architecture and design that will help with planning and projections and that provides a foundation for what is to come. Then we go iterative, incremental on lower design and implementation cycles that can be revisited, adapted, delivered, better understood.

The role of the product manager who owns/defines the product, manages priorities and the expectations and communication, who keeps the work plan up to date and manages scope, change, and risk at all times (control and execution) and who works well with the development team is key to the success of any software project. Then there is the development team, who are the stars who actually make things happen. Everyone must be accountable for deliverables and quality. And it does help to have smart, passionate and capable team and developers with code good coding practices and who understand what (good) software engineering, design and development is all about, and a management team who understands that writing software is a dynamic endeavor.


14 Aug

Java is the top programming language

According to the Tiobe Programming Community Index, Java is the top/dominant programming language (Aug 2008):

Tiobe Programming Community Index, August 2008 (Credit: Tiobe)

The same reports indicates that COBOL scores a new all time low (at position 19), yet it still is above Objective-C (at position 42)!

Top 10 programming languages:

1.    Java
2.    C
3.    (Visual) Basic
4.    C++
5.    PHP
6.    Python
7.    Perl
8.    C#
9.    Ruby
10.    JavaScript
19.    COBOL
23.    Fortran
37.    Smalltalk
42.    Objective-C
50.    Caml


[Via c/net Java still top programming language)

05 Jun

Twitter as a Case Study

Twitter logo

So Twitter is down, again.

Twitter, a great idea, but terribly designed and implemented…

Twitter is a great case study:

  • for what a badly designed piece of software is all about,
  • for what not do, or what to avoid, or how NOT to architect and deploy software (i.e. by avoiding everything they have done so far),
  • for how to NOT design and deploy your SaaS system.

But not everything is negative here; there are a lot of lessons learned, I am sure… I wouldn’t mind taking a look at what they have done, again, as a case study…

And maybe the folks at Twitter should write a book (or set of articles) on the things to avoid / not to do, when designing networked, high-availability web-based, messaging SaaS-based systems…

Update (June 8): Bad design, but perhaps, bad capacity planning….


04 Jun

Refactoring automation is like a spreadsheet

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.” — MartinFowler in RefactoringImprovingTheDesignOfExistingCode.

Refactoring automation is to S/W developers what spreadsheets are to financial planners…

In the past, when doing financial planning, you will do it on paper, and changing a variable/factor meant either re-writing or starting all again; and that took weeks. In the past, when doing code development, improving the code such as changing the name or signature of a function meant re-writing a lot, and that can take weeks (of coding and re-testing).

Spreadsheets removed the above pain and improved a whole industry; by just changing the value of a cell, the whole financial plan is automatically/instantly recalculated. Same with improving code quality; thanks to refactoring automation, just apply the refactoring technique using your favorite IDE, and all is instantly recalculated.

Refactoring automation, together with real-time errors highlighting (live parsing) probably are the two most important tools for code writers…


28 Apr

Better development tools for growing projects


As our project needs grow, it was clear that it was time for eZee to invest some dough into better, integrated tools for issue tracking, change management, and knowledge sharing. For this we acquired Atlassian’s Jira, FishEye (w/ Subversion which we already were using), and Confluence (Enterprise Wiki), respectively. While not free tools, it’s worth the investment, and having the integrated environment/tools really kicks ass, and makes my life much easier, with better project visibility for everyone…


21 Apr

Bray on “Why is Ruby on Rails so darn slow?”

Tim Bray said at his Ruby Conference keynote speech last week:

Rails is “a big deal, a hot deal”,


“Let’s face the facts: Ruby is too slow,” Bray told delegates. He says Ruby 1.8.6 – which dominates the enterprise landscape – is up to 20 times slower than Java.


“When you start to run Rails, you get wildly non-linear performance. Rails has worked well on Ruby 1.8.6… everything else is a work in progress. It’s weird and it’s hard to understand,” Bray said.

…at the end, it is about time to market vs. performance.

Read the rest at Why is Ruby on Rails so darn slow? (Reg Developer).


18 Apr

Using Static Analysis For Software Defect Detection

A very good presentation Using Static Analysis For Software Defect Detection; William Pugh, Google TechTalks, July 6, 2006:

William Pugh — I’ll talk about some of my experience in using and expanding static analysis tools for defect detection. The FindBugs tool developed at the Univ. of Maryland is now being widely used, including inside Google. I’ll give an overview of FindBugs, show some of the kinds of errors we routinely find in production code, discuss the methodology we use for enhancing and expanding FindBugs and some of the recent additions to it, discuss ways of incorporating FindBugs into your development process (such as being able to get a report of all the warnings introduced since the last release of your software), and talk about the future of static analysis, including things such as a new Java JSR to provide standard annotations for things such as @NonNull and @Tainted.«


26 Nov

Ten reasons why every programmer should learn C

The C Language is probably the most important programming language; it is fast, compact, and pervasive, and it exposes programmers to very important skills and concepts; you can't be sloppy when using C.

The C Language is the language of choice for building operating systems, other programming languages, and embedded and real-time applications. Anything truly hardcore and close to the OS is built in C.

Learning the C Language is a requirement for anyone who is serious about computer science and engineering…

The C programming Language has been a very important tool throughout my career.

See Ten reasons why every programmer should learn C.


21 Aug

Poll Results for Do you like to use Code Generators?

Do you like to use Code Generators? Below are the results for the poll:

…with the majority of the respondents indicating they like using code generators as a starting point (35%). Then comes the developers who rather (completely) write their software vs. using (or not like using) an automation tool (25%). The rest of the population are very close together: the developers who don't like the tools because are difficult to use or not useful (16%), and developers who don't understand the benefits of such tools (11%), and the developers that yes totally like to use code generators (13%). There were 83 participants from around the globe – thanks for participating!


10 Jul

Developer Poll: Do You Like to Use Code Generators?


Development tools are getting very sophisticated, helping developers generate UI, base code structure, and more.
But do you like using code generators? Or do you prefer to crank out all your code manually?
I've put together a poll to see if developers are using code generators.

You can find the poll by going to my mobility website
or on the right side column of my weblog.


09 Jul

No Fluff Just Stuff Symposium, and on Ruby on Rails


I spent the last 2 days attending the No Fluff Just Stuff Symposium here in Austin. I had a great time. Yesterday I spent the whole day listening to Dave Thomas, author of various Ruby and Rails books. Good content and presentation by Dave.

While I had read about Ruby and Rails in the past, Dave presentation opened my eyes – Ruby on Rails rocks, wow. I grabbed a photo (using my cellphone) of Dave's Ruby for Java Developers presentation, where he was comparing Java (web) vs. Ruby and Rails – I thought it was an interesting slide:

Java Web vs. Ruby on Rails

Click to enlarge

Later in the evening I saw Stuart Halloway introduce their Streamlined Ruby Studio – pretty slick tool that helps developers create an initial end-to-end base web application; I was pretty impressed with Streamlined.

The day before I also saw presentations by David Geary on JavaServer Faces (JSF). JSF seems finally mature-enough to be used, and it is an improvement over Struts. Moving forward I will be looking at JSF and possibly leveraging it in lieu of Struts.

I will be experimenting with Ruby on Rails very very soon, and will use Ruby and Rails on an upcoming project that I have. While Ruby on Rails was the “wow” for me this weekend, it might not be for everyone. Rails is heavy on naming conventions and assumptions (which is the power behind it's simplicity), and some people will feel uncomfortable with such assumptions. At the same time, it is all very flexible, and behavior that you don't like, you can override. I do still have a number of questions related to performance and security that I will try to research in the near future.

Last but not least, some words on Ruby and Rails from the mobility perspective… Ruby and Rails seems like a great tool for the web/server side of mobile (browser-based, hybrid, or standalone) applications, and/or services. The ability to quickly create a functional web-based server application and/or service, complete with standard web-services, or AJAX-like (partial data snippets) XML requests web-services, or plain old HTTP get/post resource retrieval, with back-end (relational DB) persistence, dynamic markup language generation, and a decent-looking (via Streamlined) administration web interface, again, all very quickly created with minimal coding, is just too good to ignore… The simplicity of Ruby and Rails and Streamlined is not only about quickly creating web/server-based applications, or services, but also about reducing the developer's learning curves, and about simplifying the maintenance part of the web application/service, which also are big wins.


03 Jul

Using NetBeans 5.0

NetBeans 5.0

Download NetBeans 5.0

For many, IDEs are a religious topic. For me it is about ROI – the best bang for the buck. I've tried many Java IDEs – today I use NetBeans. I've seen NetBeans grow to what it is today – in 2001 while I was at AGEA, we created a plug-in to enable NetBeans (and CodeWarrior) create MIDP applications. Since then, CodeWarrior for Wireless is dead, and NetBeans has grown to become a very nice, very competitive IDE – and it is free! Yes, I've tried Eclipse… but I like NetBeans much better. At the end of the day, IDEs are about personal preferences.

While NetBeans provides a bunch of cool features, I will admit that I don't use the UI code generators, or code generators in general – I guess that I am an old fashioned kind of developer (for better or worst). But I do use the tools that really have made software coding take a leap in recent years – very smart editors with automatic code completion, suggestions, imports fixing, refactoring, context-based access to documentation, good integration with Ant, and plug-ins that enable for tools such as (UML) diagrams. Other great features include the embedded web container, and web services. While I am a mobility developer, I don't use the Mobility Pack that much, but I use the Wireless Toolkit (WTK) quite a bit, OK, a whole lot, through Ant – the WTK is really a kick ass tool that truly have been responsible for helping developers create MIDP applications, including help educate new developers on Java and mobility. In case you ask why I like to maintain such separation through Ant, the answer is that I like to keep my own build structure and keep my build scripts clean, and standalone, and easy to integrate into the larger build processes.

The above means that I follow a “standard” directory structure, “standard” Ant scripts, with “standard” build tasks — yeap, all standard to me! It also means that when I create my NetBeans project, I create a Java Project With Existing Ant Script. This of course means I have previously created my directory structure, which is part of my Ant script, and that I (obviously) have Apache Ant already installed.

Create a Java Project With Existing Ant Script:

NetBeans 5 New Project

And point to the appropriate base and source directories, and name the project, etc:

NetBeans 5 New Project

Then to help the smart editor and code completion and refactor plug-in, etc. do their job, set the project properties to point to the libraries in the WTK directory:

NetBeans 5 Properties

That's it… we're set – the IDE and tools are ready – we're ready to code away

NetBeans 5 Editor

To build, expand the build.xml in the project window, select the appropriate build task, right click, and run the target, all from within the IDE, or I can use the command line to invoke my Ant script…

NetBeans 5 Select Build Task

To run, on the expanded the build.xml in the project window, select the run task, right click, and run! – all from within the IDE, or from the command line…

NetBeans 5 WTK