Category: Back to Basics

Down memory lane, The Agile Manifesto

With the proliferation of agile term overloads and the software suites that claim to be “agile”, how do you differentiate the noise from the real thing?

Is chaos really agile?

No, certainly not. Collaboration and working software, developers at the center of enabling business change, that for me is Agile. Chaos and unmanaged change is not.

I signed the Agile Manifesto in June of 2005:
Lizet Pena de Sola is an agilite

Every time someone tells me about the next software suite that will track all my projects and solve all my problems because it will make the “process” really “agile”, I go back and read the manifesto.
If this new software suite contradicts or impedes any of the 4 cornerstones of the manifesto, that software suite, process, administrative paperwork, extra meeting, is out. Did I mention that extra excel file logging the exact same “issues” everyone knows about and the email chains?

Here are the four main points of the Agile Manifesto, focus on the ones on the left and feel free to apply these four points to any new “agile” tool that will solve all your problems overnight. The points are great to detect baloney.

UX advice I got from an expert…

1. Give users multiple ways to achieve their goals

2. Give users all the functions they need to achieve the task at hand.

3. Be consistent in navigation, screen layout, and interaction design.

4. Use ‘widgets’ correctly. Incorrect use of widgets make people confused.

5. Assume users have no memory. They shouldn’t need to remember things about function or navigation.

6. Users are like Bears. Never surprise a user.

7. Users should never need to figure out how something works – the function of an element should be obvious from its visual design.

8. Don’t crowd screens. Just because it fits doesn’t make it OK. White space=good

9. Alignment and formatting matter. Make sure elements are presented neatly and professionally. Group similar things on the screen.

10. Iterate your designs. The more you test-analyze-modify, the better your software will be.

Thanks to Rob Lokinger from CAI Canada.

The concept of test beds or velcros for software modules…

Last week I attended a conference by Mario Cardinal at MSN Canada. The conference was part of the Toronto Architecture User Group.

The presentation had quite a few valid points along with the concept of “velcro” or test bed for modules. Test beds are a very familiar concept in electronics. In order to test hard drives or dvd drives, the manufacturer create test beds as opposed to test the parts in a computer. The same line of reasoning applies to software.

Here’s a Tech Ed 2009 presentation by Mario Cardinal.
Download Video

I look forward to see the code from this presentation at CodePlex and see what Mario Cardinal will blog after the Alt.NET conference in Vancouver, whether the same approach can be achieved with mocking frameworks.

Today (June 15th) I found the code for the Velcro project at codeplex.com. Hope this helps you evaluating this concept: http://velcro.codeplex.com/

Happy coding!

Java vs. C# access modifiers looked at by a C# programmer

I’m looking into the SCJP 6 as I don’t have hands on experience on Java projects (only academic apps).

I had bookmarked long time ago a great C# vs. Java comparison Dave Obasanjo made:

A COMPARISON OF MICROSOFT’S C# PROGRAMMING LANGUAGE TO SUN MICROSYSTEMS’ JAVA PROGRAMMING LANGUAGE



I noticed tonight that the member’s access modifiers could use some tuning and show:

C# access modifier

Java access modifier

private

private

public

public

internal

Default (package-private)

protected

N/A

internal protected

protected



In Java, a protected member can only be accessed through classes on the same package and through subclasses whether they are on the same package or not.

The protected modifier specifies that the member can only be accessed within its own package (as with package-private or default) and, in addition, by a subclass of its class in another package. Package + Kids access.

The default access modifier in Java happens when a class member has no modifier (the default is also known as package-private). This means the member is only accessible by a class defined within the package.