5 abilities that improves a productive success rate

• assuming personal responsibility for productive relationships
• creating powerful partnerships
• aligning individuals around a shared purpose
• trusting when something is "just right"
• and developing a collaborative mindset

This is a neat summary from the book: Teamwork Is an Individual Skill (ISBN 1576751554)

Agility cannot happen without collaboration, communication and feedback. But it will be even more efficient with team members realizing that its all about the people in the center... individuals are the ones that run the show :)

Another thing, as of now I have realized that the Agile term "self organizing teams" does not apply anymore because it carried a too chaotic connotation and implies weak or no leadership. There has to be a shared vision in order for a process to move forward.

Oh yeah I just remembered something I had to say here - its ok to say NO!

Over and out :)

My kicks in life... yeah I am a nerd

I love programming!! End of story, talk to the hand.. I don't care what you think. It doesn't matter if I am working as an architect, technical director or janitor. I love programming and the creative mindset you are indulging in. To just sit and juggle with different concepts and translate them into running code is just so inspiring. I am trying to pick up a new language now and then and that has really helped me cross cutting several different paradigms.

If I am bored I just pick up a little problem that has bothered me and I just fix it. Like this other day. We have this product right where a mobile device is interacting with a Java server using Hessian. I wrote most of the Java server and the Mobile application so I should know how it works. There was something with the speed of the synchronization of the data that just didn't feel right so I sat down and started writing some tests for it. The mobile application is written in C# using Visual Studio. Unfortunately there are no freeware/opensource performance monitoring tools that I know of as of now that covers that platform so I had to resort to some of my own tricks. (I might write something myself as soon as the Compact Framework team is adding dynamic proxy support to the framework.)

So after some time I discovered that during the synchronization of the data some methods were called with their arguments evaluated dynamically. These dynamic arguments are quite expensive and should not be performed during sync. So we basically have this type of situation:


// running on the client in the syncService..
while(until no more dataChanges or exception)
{
serviceMethod(extractArguments(dataChange))
...
}
public void addToChangeLog(Date date, Operation op, ...)
{
if(IsSyncing)
return;

// add to changelog...
}

...
// in the proper service method, called during sync or normal operation..
public void serviceMethod(Type arg1, Type arg2, ...)
{
// 1) do work... save to DB and so on...
...
// 2) save changes to dataChangeLog to be picked up during next sync
// but should not be done if we are syncing already
syncService.addToChangeLog(currentDate, operation,
extractNewDataAsStringVeryExpensive(sourceObject));
}

In the call to syncService.addToChangeLog we have one argument extractNewDataAsStringVeryExpensive that is evaluated before the addToChangeLog is called. This method is very expensive in terms of execution time. But this is not directly obvious when running this piece of code just a few times. Lets say the argument takes 200ms to complete and this method is called 100 times then the total execution time would be 200ms x 100 = 20 seconds. That is 20 seconds wasted.

So by changing the code to something like...

public void serviceMethod(Type arg1, Type arg2, ...)
{
// 1) do work... save to DB and so on...
...
// 2) save changes to dataChangeLog to be picked up during next sync
// but should not be done if we are syncing already
if(!syncService.IsSyncing)
syncService.addToChangeLog(currentDate, operation,
extractNewDataAsStringVeryExpensive(sourceObject));
}

...we will fix the problem but have introduced a special case check in otherwise generic code. The check whether we are syncing already has been moved one level up to the calling code. Once would think that this problem could be handled with an around advice in an aspect where we have full control of the invocation of the target method, but no. The arguments would still be evaluated before the target method was called. If would be nice somehow to be able to have an advice feature whereby you would be able to decide on what arguments to resolve before the method is called, similar to the around advice.

Take away points:

• the extractNewDataAsStringVeryExpensive method was not expensive initially. It evolved!!
• it pays of having a CONTINUOUS PERFORMANCE task in place that would run as part of the continuous integration build so that performance increasing code changes can be detected properly. This is not a trivial exercise but fun never the less
  

Well anyways, it solved my problem for now and I don't think I will loose any sleep over it :)

If I come up with a better solution I will write about it here... Ciao

Book writing

After some initial excitement regarding writing a book about software development and my experiences with it I have discovered a new book written by Kent Beck (of XP fame) called Implementation Patterns which I believe perfectly covers some of the material I was planning to write about.

I am happy that Kent (whose ideas and work I respect a lot) has published this book and look forward to read it. I still have a few ideas though that I would like to work with in written form so more about this later. I might have to change the form and approach a bit :)

Jasypt experiences

We have been using the Jasypt framework for a bit more than a year in our product and its pretty good. Very easy to integrate, configure and extend to suit your own needs.

Few things though:

- Hibernate integration: you have to think a bit about your solution if you wanna encrypt PK-FK relationships, no out of the box solution... (yet?)

- In a development environment you probably don't want to use the PBE Filter + Servlet until deployment time. If you do, you probably want to automate the initialization of the PBE system at startup from a props file via a servlet listener or something..

Scalability tips

• Asynchronous event-driven design: Avoid as much as possible any synchronous interaction with the data or business logic tier. Instead, use an event-driven approach and workflow
• Partitioning/Shards: You need to design your data model so that it will fit the partitioning model
• Parallel execution: Parallel execution should be used to get the most out of the available resources. A good place to use parallel execution is for processing users requests. In this case multiple instances of each service can take the requests from the messaging system and execute them in parallel. Another place for parallel processing is using MapReduce for performing aggregated requests on partitioned data
• Replication (read-mostly): In read-mostly scenarios (LinkedIN seems to fall into this category well), database replication can help load-balance the read load by splitting the read requests among the replicated database nodes
• Consistency without distributed transactions: That was one of the hot topics of the conference, which also sparked some discussion during one of the panels I participated in. An argument was made that to reach scalability you had to sacrifice consistency and handle consistency in your applications using things such as optimistic locking and asynchronous error-handling. It also assumes that you will need to handle idempotency in your code. My argument was that while this pattern addresses scalability, it creates complexity and is therefore error-prone. During another panel, Dan Pritchett argued that there are ways to avoid this level of complexity and still achieve the same goal, as I outlined in this blog post.
• Move the database to the background - There was violent agreement that the database bottleneck can only be solved if database interactions happen in the background.

(src- http://natishalom.typepad.com/nati_shaloms_blog/2007/11/lessons-from--1.html)

Roughless Pragmatism or RP

Rule 1 of RP: Never paint yourself into a corner

This rule basically states that when you design software in an agile manner (i.e evolutionary design) always make choices that allow for maximum flexibility. This could translate to different things to different people and is really quite subjective. That is what is great and wonderful with software development, its so creative and yet technical and abstract at the same time.

Software development is all about having abstract thought models in your head. Its very unnatural to live in one reality (our dimension) and act in it based on another reality (some conceptually compatible, yet a very much simplified one.) This is where OO, DLS and so on comes in. Tons of stuff have been written about this :)

More rules will be posted as they are realized...

Distributed web architecture with Spring

Overview
I have been working on a fairly interesting distributed architecture for some time now and this post describes this work. What makes this architecture interesting is the use of AOP to externalize coordination and communication between a various instances of the same server.

In this architecture a server can run in either:

• Single mode - in this mode the server encompass both the master and slave modes
  
• Master mode - in this mode the server serves as the main entry point for requests. A master can interact with several slaves depending on availability
  
• Slave mode - in this mode the server is serving as a slave awaiting requests from a master
  

A server running in single mode is what we typically understand when we talk about a server. It really only becomes interesting when we are breaking this server up into a distributed topology. All extra logic to handle the difference between these is handled by aspects. The master is the central coordinator in this configuration and dispatches requests to a potential slave when needed. The master contain all information on what requests to handle locally or which ones to dispatch to a slave.

AOP interceptors are used to handle the extra logic that has been extracted from the master and slave. Both method interceptors and request interceptors are used. The method interception is used for things like user creation, user update, invitation and registration. The request interception is used for functionality that should be handled by a slave.

This type or implementation gives a lot of flexibility in that once the single server is implemented the master and slave specifics are added on top as aspects. This makes the architecture easy to configure and modify. The architecture has been made modular such that the master and slaves together forms a single server that is driven by a single interface via a web browser.

The request dispatching mechanism cooperates with Registry in order to dispatch the slave specific requests. The configuration of these requests is stored in a application context configuration. The UI is constructed on the master/single server but individual requests are processed based on the request configuration. To make it simple, it is assumed that all requests are processed by the master/single server unless configured to be processed by a slave. What slave to dispatch the request to is dynamically determined by the Registry. All slave servers registers with a central master server upon startup.

Once a user logs onto an master, a session is also created with the slave associated to that user. The session is stored in the registry. The slave to authenticated against is defined during user registration where the slave is determined.

Both the master and slave server stores the same user information. This is needed in order to be able to handle all the various use cases.

The beauty of aspects I that they can be applied to code to add new functionality that was not originally thought of. Code or functionality can be decorated with new functionality. Another powerful benefit with aspects is that they allow for common code that crosscuts different conceptual areas to be externalized and thus be shared which reduces the amount of code that has to be written.

Writing a book

I am very excited. I am back home in my home town in Sweden and met up with a really smart friend of mine from when I was younger. We dont meet up very often but when we do we always spend quite some time discussing various topics from politics to computer science and philosophy (often not leaving a single drop of Glenmorangie left.)

We have both been active working in the software industry for quite a few years now so you can imagine that our discussions can become quite animated when it comes to sharing our experiences.

For some time now I have been experimenting with the idea of writing a book about my exeriences in this field and how I feel about developing software and my passion for it. And as I mentioned this to my friend he got so interested that he suggested what we should do this in a joint fashion, and I though that was an excellent idea.

So we have now started this little project which I think will be a really cool one. I dont expect anything really other than it being a learning expericence for me/us. And as my former coworker (mr potatoehead) - "Frick", once explained to me, once you are explaining something to someone, you are focusing and structuring your thoughts in such a briliant way that the world is clear as mud.

NORM

I have been working on a little framework that I think might be useful then developing applications on a Compact Framework device. Its an ORM for PDA's inspired by Hibernate. I developed the initial framework in a day or so just coding away in a nice flow fashion and I am quite happy with the result. Its called NORM and is available from here.

The basic idea was to try to abstract away all the SQL specific stuff from the programming model to allow for working with POJO's as easy as possible. Lets just say I got one step to bored with having to think/work/program in terms of Tables, Rows, DataSets and so on in .NET. For me that is just to low level. I want to work with proper objects (POJO's), and I want the CRUD operations related to these to be as transparent as possible. The less code I have to write the less I have to worry about.

The framework itself relies heavily on Annotations and Reflection as I am a strong believer in a self-contained representation model. Thus I should not have to configure something unnecessarily in a configuration file (XML or something similar) when the intent can be clearly specified in the class file itself.

Some basic assumptions regarding the framework

• The schema must match that of the domain model (currently working on an schema auto-generator)
• There is a one to one relationship between a table and a class name (unless otherwise specified using an Annotation)
  
• There is a one to one relationship between a field and a table column (unless otherwise specified using an Annotations)
• The many2one relationship must follow: (src table) id -- field_id (foreign table)
  

This is implemented so far:

• All fields are persisted unless [Transient] is specified
• All fields are persisted unless [Transient] is specified
• Only classes with [Entity] can be persisted
• Strings are assumed for all fields unless the Id is field
• The Id field is an Int32 which cannot be null so it is assumed that a class with Id == 0 is fresh and can be inserted
• Attributes to specify the persistence option:
• Entity (speficies that this class is persistable)
• Id (speficies this field to be the primary key)
• Component (flattens the the object graph)
• Transient (do not persist this field)
• Inserts an object graph (semicascading)
• (Only persists object with the [Entity]attribute specified)
• (Only fields != null are included)
• (If the id != 0 dont bother with generating an insert)
• Update individual objects
• (No dirty checking but only fields != null are included)
• Load an object and automatically populate it with the data from the DB
• Supports QBE whereby only fields != null are included
• Load an object graph (shallow cascading)

Features that I am working on at the moment

• Collection support (requires implementation of laziness)
  
• Dirty checking (requires a 1 level cache, Session or something)
• Support for more databases and dialects (currently only SQLite)
• Persistence by reachability (no dynamic proxies in CF, so have to rely on a CRUD service)
  

I am looking for developers that are interested in contributing to this framework. If you have been using NORM in a project yourself please drop me a line or two and tell me about your experience. Any feedback is more than welcome.

More information is available from the sourceforge.net site...

Groovy vs. Ruby

Both are very compelling and provide with very powerful abstractions...

but...

• I don't really like the syntax in Perl and unfortunately Ruby is living in that space..
• Groovy seems a bit lagging behind in areas like parallel assignment
  
• No good IDE support overall, maybe next year :)

despite that...

• Groovy really shines with its natural Java blending capability
• I love the Grails project, showing what is possible with Spring and Hibernate
  
• Dynamically typed languages are just sweet... write less and no interruptions in your flow
• Groovy just added Annotation support, that is way cool
  

I devoted some nerd-time to learn both last year and I really enjoyed the exposure. I think its important to experiment with different conceptual tools such as programming languages from different paradigms as it expands on the set of potential solutions you can dream up for a particular problem.


So for example...
Say for example how nice it would to be able to do something like this in Java:

Map stuff = {"locale" : "en", "theme" : "basic" }

...but of course we cant so we have to resort to something like this:

Map stuff = CollectionUtils.asMap(new String[][] {
{"locale", "en"}, {"theme", "basic"}} );

There is nothing in Java that is called CollectionUtils.asMap(String[][] map) so we have to create this ourselves, but without the exposure to the Map construct in a higher level language like Groovy it would be less likely that we would create a method asMap() as in the example above just because we had not experienced or perhaps not understood the power of such an abstraction.

Hmmm, so why is this so powerful, well it has to do with expressiveness and preciseness. Math is an excellent example of how you can cram vast amounts of precise knowledge together to describe a phenomena in nature... but just as Perl its syntax is quite obnoxious. I think I like math more :)

The way of Scrum

Was talking to my good friend about planning a software project and I wrote down this little overview on how I tend do it but it could change from one project to another...

Initial setup
You do an initial inception/elaboration phase where scoping takes place. Not all requirements are gathered here through. Maybe 30%-40% of the major ones.

Then for each sprint (iteration) you do analysis, design, development and testing over and over again. You find more requirements here maybe around up to 80%-90%. You should do integration here progressively.

Rule of thumb NEVER WAIT UNTIL LAST MOMENT WITH integration, testing, security and so on.

Then in the Closure/Transitional phase you complete/finalize the project.


Details around Scrum and Agile project development
So lets say you have a 4 week sprint (with is the name of one iteration when)...

So each software component would have to be broken down into smaller chunks that each should not take more than 8-16 hours (1-2 days) to complete. With completion here I mean:

Analyzed, designed, implemented and tested.

Backlogs
The team of stake holders would sit down and decide what the project should deliver. The following artifacts are produced:

Product Backlog - for the whole product (very high level, specifies the complete product)
Release Backlog - for a particular release (more details added, subset of the product backlog, for a release say v1.5)
Spring Backlog - features picked for a particular sprint, subset of release backlog (1 iteration worth of features)

The process and phases
So the Scrum project is divided into the following phases:

1. Review release plans (done by developers, picking from the backlog)
2. Distribution review and adjustment of product standards (done by developers)

This is where the majority of the work is done

3. Sprint (developers doing work, 4 weeks typically)
4. Sprint review (by stakeholders to determine next sprint, determine completion based on complexity and feedback)

5. Closure (last finishing activities, debugging, optimization, marketing and release)

So lets say for a 5 sub-projects and 5 components gives you 25 items in your backlog

So given that you have 5 months to complete the project you can break down the backlog into roughly 25/(4/20) = 125 chunks per sprint. So say you have 5 people in our team then each developer will work on around 25 chunks per iteration. That is your backlog "Burndown" rate... something called the project velocity in XP and other agile methodologies.

You need to be able to keep track of the Velocity in order to be try to track how the project is progressing. You need this as you would want to to be able to check your estimates... So lets say that one spring your velocity is 25... then if you calculating backwards you will find that you will be able to do 125 chunks based on having a team of 5 developers. But say that for one sprint your velocity is only 15 then you know that for the same number of developers you can only deliver 75 chunks so that will be your estimation baseline for the next sprint... So by using these instruments you can adjust the project plan and sprint backlog accordingly.

Dont make me think

Interaction design is such an important craft when designing a professional looking website. The interaction designer not only has to get his/her head around the concepts around the product but also designing a look and feel that would help potential customers to use it efficiently and also would want to come back and use it again.

This is much harder that some people tend to think. It usually takes only a few seconds to decide whether you like a site/UI or not. What are the factors?


Look (colors, fonts, size, and layout) and Feel (does it do what I expect it to do)

The Look and Feel should be covered by the interaction/graphical designer.

Speed (it should load fast, its that simple)

Ajax has helped tremendously to speed up various aspects of a web site. There is usually no need to refresh the whole page as we only work with smaller areas of a page such as:

• updating a table and showing a summary
  
• loading and hiding/showing an article
  
• store a poll result and then displaying a result in a tooltip window
  

There is surprisingly little that is needed to add Ajax to a site:

• Knowledge of some kind of Ajax framework (there are quite a few out there)

or

• Javascript and the IFrame tag (if you want to do it yourself)

I would recommend to use an already existing Ajax framework as it usually handles browser incompatibility issues pretty nicely.

A comparison of some of the good ones out there can be found here - http://www.devx.com/AJAXRoundup/Article/33209

Profound

That which we persist in doing becomes easier - not that the nature of the task has changed, but our ability to do has increased!

Thoughtful Statements

I love this one from my very good friend Frederico:

Sniff, sniff...
what is that smell?

The smell of success :)

New Milestone Release

Aaaahhh, its a nice feeling directly after a milestone release. A milestone is like a heartbeat. You plan, live and evolve around it. We work so hard preparing for the release, the stress, the little features we agilitly include or exclude... very exciting to slowly see the whole application taking shape :)

This project has been a great success I think where I have been able to fully experiment with my ideas and principles around agile software development. I will write some more about my discoveries in some later posts but to summarize:

• Deciding what to do and how to capture requirements
• It all starts with an idea, you need to break it down, nothing is cast in stone
• Prototype early and think RAD
  
• Putting together a team
• You must pick skilled people that can work well together
  
• Pick people that you like and can trust!
  
• Communication is key (natural, problem domain and pattern languages)
  
• No synergy is like swimming in Tar!
• There can be no substitute for skill and experience!
  
• Drawing up the initial architecture
• There cannot be a democracy here, to many architects is very destructive
• The principle architecture can be found in numerous existing frameworks
• Put metadata in the code and abstraction in the configuration
  
• Be pragmatic
  
• The software development process
• Iterative and incremental
  
• Usecases, stories or features? Doesn't matter, as long as you can break it down into chunks that can be understood, estimated and prioritized.
  
• Planning a release
• Never move a deadline, de-scope if you need to!
• Announce the features to be demonstrated early. This makes the target clear!
• Prioritize, not everything is important!
  
• Developing the code
• Coding standards are very important!
• Don't let just anyone touch the code
• Test driven development is key
• Refactor the code often, strive for simplify and elegance
• Reuse good ideas, best practises and principles, no need to copy&paste code then!
• The code is the documentation and the unitests are the requirements
  
• Document the intent, the idea or principle behind the code
  
• Tools for collaboration and issue tracking
• Issue trackers, wikis are key
• Use whiteboards often
• Don't send emails if you can walk up and talk directly with a team member
  
• Make sure information is shared
  
• How to demonstrate your software
• At the end of a milestone, demo the initially announced features
• Be swift, make sure every feature is demonstrated properly
• Take time to write down all comments from stakeholders
• Let members in the team take turns in demonstrating new features as this ensures that knowledge is shared evenly
• In general
• Be eager to learn something new every day
• Be helpful and humble but make no mistake, be proud of your craft and skills!
  
• Don't complain, do something about it, be pragmatic
• If you break the build, you fix it!
• Don't think X hours a week, think Y issues done/left.
• Measure the velocity by ensuring that most issues are broken down evenly
  

On Monday it all starts again with release planning. We are now one milestone from the first candidate release. I don't expect us to release more than 2 release candidates at most.

Being so close to a release candidate I am now breaking down the milestone into smaller weekly point releases, one every Friday. The reason for this is so that we can test the codebase more frequently (as we don't have a testing team available) and also to allow for faster feedback from the stakeholders and still allow for a practical development cycle length.

Once all this is done, we will all chill out on a beach in Thailand drinking a MaiTai feeling absolutely in peace with the world...

Why?

Because we deserve it :)

Observations

1. It gets lonely on the top. If you don't have any good connections with the upper level, you are lonely as hell.
2. You can, but its intrinsically quite difficult to be friends with your stall. The respect dictated by the employer/employee relationship somehow prevents it from happening...
3. apply 2 to 1 and there you go
   

7 Habits of Highly efficient People

A great statement here that I like:

"It is motivation that gets you started, habit is what keeps you going!"

So how can we define habits?

As we grow older and wiser, we also change our outlook in terms of how we perceive our self's and others in terms of dependability.

• Dependence - the paradigm of you. You take care of me, I blame you...
  

• Independence - the paradigm of I. I can do it, I am responsible...
  

• Interdependence - the paradigm of we. Together we will succeed...
  

In order to become more effective we need to balance the production of desired results and our capability of the same.

In effect its all about balance short term gains with long term goals.

We are responsible for our own effectiveness, for our own happiness and ultimately for most of our circumstances...

Pretty much, you are the results of your own actions :)


The 7 habits defined

• Proactivity
• Begin with the end in mind
• First thing first
• Think Win Win
• Seek first to understand, then to be understood
• Synergize
• Sharpen the saw- become better, keener and more efficient

Have a nice day :)

Pursue your dreams baby...

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." - Albert Einstein

I have been thinking lately about what drives us humans to pursue things. We all have dreams, issues or tasks that we very often don't do anything about even though we know we should. Its almost like the threshold is to high, the risk to great or our priorities are all screwed up.

Its always there, the feeling that something should really be done about this, but not now...

"Lets wait, It can always be done tomorrow"

We postpone this thing we want/need/must do in order to preserve our sanity until its unbearable. Why? I mean how often really do we suffer from this limited form of cognitive dissonance?

Its stupid!!!

The Boss

So we have all had them one or another time. The Boss. We either hate them or love them. Here are am listing two, I think, extremes that I have come across..

Which one are you and why do you think?

• The evangelistic motivator

• The Brutal enforcer
  

From a tactical point of view they both gets things done. But strategically, how does it all pan out?

The Brutal enforcer with his super pragmatic no-nonsense attribute does not stimulate to do things because you want to but because you have to. Its all about governance by fear. In the long run this personality trait will never succeed because people will be worn out. Fear of speaking ones mind, fear of making a mistake or appear less skillfull totally violates the idea of collecting feedback which it so important in order to successfully run a business. The Brutal enforcer is creating rules for anything and everything. He is the killer of creativity. He is never happy and rarely complements on a good work done. Luckily there are not to many of these people in leading positions very long or if own the company you are working for you smoothly switch to a new department/company real soon :)

The Evangelistic motivator is on the complete different side of things. He is there but not there at the same time. He is leading by example. The way he teaches is not to say DO THIS, but stimulates learning by asking things like WHAT IF and HOW COME? Basically this personal is interested in things outside the problem domain you are working in. He is interested in you. He puts people in the center and allows for synergies to happen by gently presenting the vision or goal and not enforcing anything. He trust that the people he has hired are up to the Job as they all passed the interviews they had to go through. Unfortunately there are not to many of these people available as this skill is very difficult to obtain. This is something part innate and part trained.


Conclusion
Even though the work must be done it cannot be done on the basis on governance by fear. The system will eventually break down.

It is so important to have good personal skills. You need a great EQ in order to motivate and stimulate people to do things. This way you create synergies by getting so much more that just the work done.

The responsibilities of a software architect

After having been working as an software architect in various companies for 10+ years I would like to offer my humble opinion in this matter.

I like the idea of conceptual grouping of what we do when developing software. RUP defines 4 such groups that can be used to describe the various phases a software project can go through.

• Inception
  
• determining whether its worthwhile going through with the project
• setting up prototypes
• gauging the complexities
  
• Elaboration
  
• gathering most significant functional requirements
• building candidate architecture and functional skeletons
  
• defining the non functional requirements
  
• setting up the project (defining standards etc. etc.)
  
• hiring people, etc. etc.
  
• Construction
  
• implementing more functionality and features
• gathering more requirements
• changing requirement and implementation if needed
  
• Transition
  
• finalization, making battle ready
• releasing
  

We can think about software development in this way:

1. There is a need for computer program to be implemented, and the reasons can be:
   
• economical (we need to save money or make more money)
• human (as a tool, visualization, training)
  
2. Try to define what we need this computer program to do for us
   
3. Try to come up with the best possible way known at the time to do this, best here can be:
• fastest
  
• most elegant
• cheapest
• most compliant
4. Commence with implementation following some kind of process, best practise here:
   
• iteratively
• incremental
• use case/scenario/story/task/feature drive

Some tools and principles that I have found that will aid in this activity:

1. Continuous integration
2. TDD
3. Refactoring
   
4. Scripting languages
5. RAD
6. Separation of concern
   
7. Issue tracker
8. Wiki (with support for active discussions)
   
9. There is no substitute for skill and experience!
10. Communication and feedback
11. KISS
12. YANGNI
13. Code reviews
14. Curtness, humbleness and mutual respect
15. Managing expectations
16. Avoid rather than detect problems but handle gracefully when so
17. Collective ownership
18. Delegation is a great way manage time
    
19. Open source tools of all kinds...
    

Here are some of the responsibilities I would expect from a software architect in short form:

• Requirements gathering and synthesising
• System architecture - servers, routers bandwidths and so on
• Nonfunctional requirements - capacity planning, scalability and performance conformance
• Application architecture and design coming from some kind of analysis based on the above
• Setting up project and hiring people
• Setting up candidate architecture and skeletons
• Establishing coding guidelines and standards
• Establishing project methodology and process
• Deciding on tools for development, communication and management
  
• Training people
• Documentation
• Analysis, Design and Implementation - Hands on!

These are some of the attitudes I think a software architect should have:

• Enthusiastic
• Evangelistic
• Humble
• Clear and to the point
• Agile
• Pragmatic
  

The architect is the driver, the leader and the motivator. Without a good architect there can be no supper tomorrow :)

Sunny sunday...

Ah, yet another hot day here in Singapore. Sitting here in front of my computer when I can be outside in the sun.. arghh guilt :) Tomorrow I will get a new laptop so that I can sit outside instead. Cool thing with Singapore is that WiFi we be free from 2007 with more and more hotspots coming up every week.

Have been thinking a bit about the balance between knowing the specifics of something (like an API) and the generic (like how to build an API.) Knowing an algorithm, mechanism, approach or process that produces something specific must intrinsically be better than knowing the specifics only, right? I mean specific knowledge is hard to obtain because it requires exposure of one or another kind.

So in order to solve a problem for example, our ability to do that within an acceptable amount of time and with quality must be a function of our experience and a combination of generic and specific knowledge. How can we measure knowledge or the level of? What constitutes great knowledge as opposed to lack their of? One could argue that keeping lots of facts in ones mind constitutes a great level of knowledge.

But what about the ability to extract facts from a huge mass of data and derive some kind of knowledge from that? We typically filter away huge amounts of information every second but some we keep, why do we keep some and filter away some? And why don't I sometimes remember something I know I should remember? Its like my mind selectively "forgets", and other times I remember things that carry much less value.

So please brother Brain, can you please remember to turn off the aircon in the living room next time I leave for a 2 weeks holiday to Sweden.

Using the New Blogger !beta :)

So now its 2007, I have visited all my relevant relatives and friends, I ate the fat (but very nice) Swedish Christmas food and (probably even added a few ponds to cover my layer of strong and hunky six pack) and are on my way back to Singapore. I have been waiting here at Heathrow since 11 am and the flight takes of 22 pm tonight... AARGHHHHH :) Its was a really great and relaxed holiday but now I feel refreshed and energized for the tasks ahead.

This new Blogger works like a charm, I am really happy with it. Expect at least a few postings a week, he he.

This year will be very exiting as we are getting closer and closer to the release date of the product we are developing. I have organized the various tasks evenly among the team members and hopefully with some hard work we will be done with the 1st version by end Q1. There are very few outstanding requirements left to resolve so that should allow us to get the major outstanding issues out of the way by end January.

The major one right now that I will try to have done by next week is to programmatically configure Hibernate with mapping information so that I can generate proper HQL based on the map structures I pass in. This will be powerful and tremendously flexible. I finalized the work on the PDA before I left on holiday 1 week ahead of plan so that is sweet. I will have to add some more tests on the Java side but that should be pretty easy. I cant wait until I get all done end Next week to see how much faster the synchronization will be.

Furthermore I will have to add code to dynamically generate the schema (DDL code) based on the Book metadata passed in to the LibraryService when associating a Book to a User but I will defer that until later. Right now I have hand coded the tables and that should enough for now.

I have also come up with an upgrade plan for the metadata and code on the PDA. I will write more about that later but its pretty sweet I think. Its based on the path of least resistance (one of my favorite design approaches.)