The Franciscan Report

VS.Net template for Test Driven Development

2007-04-12T14:56:00.000-07:00

I've found this template to be very useful for codegen TDD classes for me.

http://blogs.ipona.com/dan/archive/2007/01/02/SimpleTDDVisualStudioTemplates.aspx

Jay Fields Thoughts: Ruby Form Template Method Using Extend

2006-09-20T11:27:00.000-07:00

Jay Fields Thoughts: Ruby Form Template Method Using Extend

One of Ruby's feature is the introduction of 'mixin' as demonstrated by Jay's article.

I have a mix feeling about using this feature (no pun intended). To me mixin sounds too close to global function as popularized by language such as C++.

In C++ you can use this "global" function in your class with the right syntax and inclusion. Obviously one would argue what's so bad about that. In the beginning if you have small codebase maybe the drawback is not as obvious, but maintaining this type of code years from now could be hassle in my opinion.

I guess what I'm trying to say things could go out of hand quickly by incorporating this practice.

Suzanne Cook's .NET CLR Notes : New Assembly, Old .NET (and Vice-Versa)

2006-08-15T14:01:00.000-07:00

Suzanne Cook's .NET CLR Notes : New Assembly, Old .NET (and Vice-Versa)

To load the assembly compiled using the previous version of .Net framework such as 1.1, or lower, from a .Net 2.0, you don't have to do any extra effort.

However, things are not the same the other way around, to be able to load a .Net 2.0 assembly from a previous version of .Net you have to add this into your App.config

 
<startup> 
    <supportedRuntime version="v2.0.50727" /> 
    <supportedRuntime version="v2.0.50215" /> 
    <supportedRuntime version="v2.0.40607" /> 
    <supportedRuntime version="v1.1.4322" /> 
    <supportedRuntime version="v1.0.3705" /> 
    <requiredRuntime version="v1.0.3705" /> 
</startup>

This will allows such case, assuming you have the required version of .Net and the supported runtime version of .net 2.0

Data Segregation

2006-07-28T09:08:00.000-07:00

Enterprise applications usually use some type of framework to support their underlying applications. Framework can vary from a simple reusable components such as a Math library to a more complex solution such as a mechanims to handle Messaging, Security, etc. Some of the more complex framework requires access to external data storages such as database or a queue, etc.

There are two options on how applications code deploy with this framework's external resouces. One solution is to share the framework's resources amongts all applications, thus data specific to those applications will be stored in the same storages/tables.

The other solution is to store data specific to the application into its own database domain, thus creating a physical boundaries between different applications.

There are pros and cons of both approaches which I will discuss as follows;

The benefits of using the same physical storage for all data are:
- Easy to implement
- Development/Support teams will only have to look at one place to find the data.
- Easy to maintain from the sense where update to data schema will only need to be applied in limited places.

The disadvantages of such solution are:
- Data from different applications are tighly located in the same place.
- No way to protect the integrity of the data of other applications, since different team could potentially affect other team/application data.
- Depends on certain situation/application behavior, there could be performance impact since all applications will be using the same data storage.

The benefit of using segregated data storage:
- No need to worry about affecting other application data, when doing updates/modification to the tables
- If security is a concern, using database to enforce sensitive data between applications is easier to implement.
- No data violation could happen, in a case where some record could have the same values but different meanings, but if the data are stored in the same table, there could be some constraint violations.

The disadvantages of this approach:
- More work for support team, when they have to maintain all applications, thus tools need to be created to leverage this problem.
- Upgrade of data schema need to be applied to more places, but depends on how you implement the schema changes this could work for the benefit of the applications that couldn't afford to have the update yet.

#region ... #endregion

2006-07-07T07:34:00.000-07:00

#region my rant

Microsoft introduces a keyword #region ... #endregion that supposedly can be used to organize "like" codes into itsown region.

However, lately I have been encountering that it's also used as a somewhat of an excuse to have big classes. Somehow the use of #region makes it a little tolerable to have big classes.

I don't know if this is what Microsoft intends or not, but it's clearly not an appropriate solution to say the least.

The problem with big classes not only because it's not pretty to our eyesight, but there are some other basic problems with them:
1. Big classes are usually hard to test.
2. Big classes are usually error prone, because regardless of how we divide it up in regions, we still have to understand details of the class, and most humans usually comprehend things as smaller chunks better than one large chunk.
3. The use of region itself should have triggered the fact that the class might have low cohesiveness, thus they could be broken up to smaller classes.

The problems with region are:
1. It's another thing that we have to maintain to make sure things in the region are all "related", I have seen many times, that region starts out well but become "stink" over time.
2. Who's deciding what region to create, which code should go to which region, etc. This is left to each developer interpretation, should we have code review for the region ;-)

#endregion my rant

SQL Injection Attacks

2006-06-22T21:31:00.000-07:00

Ways to prevent SQL Injection Attacks

A few ways to avoid SQL Injection attacks.

In .Net

Instead of

using( SqlConnection con = (acquire connection) ) {
con.Open();
using( SqlCommand cmd = new SqlCommand("SELECT * FROM users WHERE name = '" + userName + "'", con) ) {
using( SqlDataReader rdr = cmd.ExecuteReader() ){
...
}
}
}

Use the following

using( SqlConnection con = (acquire connection) ) {
con.Open();
using( SqlCommand cmd = new SqlCommand("SELECT * FROM users WHERE name = @userName", con) ) {

cmd.Parameters.Add("@userName", userName);

using( SqlDataReader rdr = cmd.ExecuteReader() ){
...
}
}
}

In Java.

Instead of

Connection con = (acquire Connection)
Statement stmt = con.createStatement();
ResultSet rset = stmt.executeQuery("SELECT * FROM users WHERE name = '" + userName + "';");

Use the following

Connection con = (acquire Connection)
PreparedStatement pstmt = con.prepareStatement("SELECT * FROM users WHERE name = ?");
pstmt.setString(1, userName);
ResultSet rset = pstmt.executeQuery();

Data Driven Design

2006-06-14T21:19:00.000-07:00

Data Driven Design is generated based on the need to provide users of the system with a set of data.

The common flow of the system will be as follows;
1. A data access object or a business entity object will retrieve the particular data from a database either through stored procedures or dynamic sql statements.
2. The resulting query result will then be mapped to a collection of data objects (usually an anemic model, ie. model with data only, no behavior) representing the information requested by the user.
3. Logics can be embedded to the business entity object (usually contain just behavior with no data member) or the data access object if necessary to act on the data object.
4. This data object will then be passed along to the user to be displayed in the presentation tier. If it needs to cross multiple physical tiers, then this data object is usually called a Data Transfer Object.
5. If the user can resubmit the data back to the server, then the aforementioned business entity object or the data access object can be used to validate user entries.

Benefits of this approach are:
1. It's a more procedural approach in software development, thus doesn't require deep domain expertise.
2. It's easier to implement since data objects are created based on user requirements.

Disadvantages of this approach are:
1. Business logics could be scattered around the system, thus could potentially create accidental duplications (root of all evil).
2. No ubiquitous language and understanding between development team and the business folks, since nobody speaks in term of the actual business domain.
3. No logical boundary exists between inter-related objects, thus could potentially lead to a highly coupled systems.
4. Most of the cases the data objects will be closely mapped to tables in the database, thus it might not take advantages of what Object Oriented Design principles give, ie. polymorphism, inheritance, composition, etc.

Compare this approach to a Domain Driven approach which value system as a set of domain objects and how they are inter-related with each other, which can be defined/contained within their own boundary.

Stored Procedure vs Object Relational mapper

2006-06-13T11:31:00.000-07:00

Enterprise application team has a constant battle of whether to use stored procedure or OR mapper.

Despite some common myths about O/R mapping framework such as performances, sql injection attacks, one to one mapping between tables and classes, which are not true of course.

Here are my takes on the subject

Benefits of using Stored Procedure
- SQL codes are precompiled thus can improve performance
- Prevent SQL injections.
- Works very well with data intensive operations that return huge datasets.

Disadvantages of using Stored Procedures
- Developers need to know the language, thus becoming language dependent.
- Need to implement complex mapping layers between the returned data and domain objects
- Need to maintain the SQL codes
- Business logics could leak into the stored procedures.
- No tool supports for debugging, refactoring, code coverage.

Benefits of using OR Mapper
- Developers deal with domain objects directly instead of having to write their own SQL codes.
- Eliminate repetitive database access codes
- Most OR Mappers (NHibernate, iBatis, etc.) provide caching, lazy loading, optimistic locking, dirty saves, business transaction mechanisms.
- SQL injection is never an issue, since most of the underlying frameworks prevent it
- Support for inheritance, composition, one-one and many-one, many-many associations
- Support transaction updates across tables/rows/objects.
- Objects dependency ordering during DB operations.
- Paging supports
- Cascading updates/deletes are supported out of the box.
- SQL statement batching, sending multiple statements to the database in one shot.

Disadvantage of using OR Mapper
- Have to maintain the mapper schemas
- More performance impacts compares to using Stored Procedure, in particular, if the application is a data intensive operations, ie. batch processes, projection types queries, etc.

I believe both methods have their places, if you want complex logic in a user interaction then using domain objects with O/R mapper is the way to go. On the other hand, use stored procedures if you need to perform large dataset queries, or batch jobs.

Layered Architecture structure in .Net

2006-06-08T12:49:00.000-07:00

Common .Net practice is to write software in a solution file consists of multiple project files. A project file corresponding to a dll.

There are two options where one could structure his layered-architecture concept in .Net projects.

One is to structure the layering to corresponds to individual project, thus one layer per project. The benefits of this approach are:
- It allows flexibility in swapping dlls in and out of an application.
- It's quite easy to separate the work between development group, particularly in an organization where developers are segregated to different area, ie. DB developer, Service developer, domain developer, thus each group can develop their own module independently.
- Each individual layer can potentially be deployed in different physical tiers.
- It allows creation of patches to fix defects that only affect certain area of the applications, thus it promotes faster build time and "minimal" risk.

The disadvantages of such approach are:
- We lost the advantage of encapsulation, for example, as different layers are package to different dll, there's no way to limit other projects from referencing dll that they are not supposed to.
- It's easier to adopt the concept of SOA, where the only way to gain "business access" is through external service call, instead of allowing direct access to a particular business objects or data access layers in the worst case.
- The effort to maintain dll's dependencies as the application grows larger could create maintenance nightmare.

The other approach is to use namespace to produce the logical layering. This technique has some benefits, such as:
- It allows the use of assembly level access to limit direct access to layers that other dlls are not supposed to have.
- It allows the use of tools such as NDepend to set up dependency structure between different layers.

In conclusion both approaches have their places in an application development.

Separating module to different dll works well for a module that's being shared across physical tiers, for example the domain objects module.

Common components could probably be separated into their-own dlls, to some degree, since applications that use web component probably doesn't need to include windows component. The rule of thumb is "things that work/used together stay together".

As far as some of the benefits listed above for separting layers to different dlls, one must ask the following questions:
- How often have we ever swapped dlls in and out of applications in practice?
I'm a big supporter of Simplicity and Minimalist concepts, therefore we do things the simplest way now, and when we need to use separate modules in the future we can still do it with ease, since we have separated those layers into different namespaces.
- We have bigger issues on hand if an organization is more accustomed to specialist developer rather than generalist developer in my opinion.
- Deploying different modules in different tiers only make sense in some cases, for example, presentation tier and server tier, but in other cases we have to question the benefit and the performance impact of doing so.
- Fixing defects rarely only touch one logical layer. Also, most of the time spent when promoting patches is not in the build process but in the QA testing (manual or scripted). Continous integration and TDD practices can minimize any risk associated with "patching" a portion of codebase vs. the whole codebase.

Brad Appleton's ACME Blog: Simple ain't Easy: Myths and Misunderstandings about Simplicity

2006-06-02T08:22:00.000-07:00

Brad Appleton's ACME Blog: Simple ain't Easy: Myths and Misunderstandings about Simplicity

My favorite quotes from the blog.

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
Three Rules of Work: Out of clutter find simplicity; From discord find harmony; In the middle of difficulty lies opportunity.
-- Albert Einstein
For every problem there is a solution which is simple, clean and wrong.
-- Henry Louis Mencken
Think simple as my old master used to say - meaning reduce the whole of its parts into the simplest terms, getting back to first principles.
-- Frank Lloyd Wright
Beauty of style and harmony and grace and good rhythm depend on simplicity.
-- Plato
The ability to simplify means to eliminate the unnecessary so that the necessary may speak.
-- Hans Hofmann
Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.
-- Charles Mingus
Everything is both simpler than we can imagine, and more complicated that we can conceive.
-- Goethe
The whole is simpler than the sum of its parts.
-- Willard Gibbs
The pure and simple truth is rarely pure, and never simple.
-- Oscar Wilde
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius--and a lot of courage--to move in the opposite direction.
-- E. F. Schumacker
Besides the noble art of getting things done, there is the noble art of leaving things undone. The wisdom of life consists in the elimination of nonessentials.
-- Lin Yu Tang
Very often, people confuse simple with simplistic. The nuance is lost on most.
-- Clement Mok
You can't force simplicity; but you can invite it in by finding as much richness as possible in the few things at hand. Simplicity doesn't mean meagerness but rather a certain kind of richness, the fullness that appears when we stop stuffing the world with things.
-- Thomas Moore
The point of philosophy is to start with something so simple as not to seem worth stating, and to end with something so paradoxical that no one will believe it.
-- Bertrand Russell
The aspects of things that are most important to us are hidden because of their simplicity and familiarity.
-- Ludwig Wittgenstein
Manifest plainness, Embrace simplicity, Reduce selfishness, Have few desires.
-- Lao-Tzu, Tao Te Ching
Simple things should be simple and complex things should be possible.
-- Alan Kay
The key to performance is elegance, not battalions of special cases. The terrible temptation to tweak should be resisted unless the payoff is really noticeable.
-- Jon Bentley and Doug McIlroy
... the purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.
-- Edsger W. Dijkstra
Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.
-- Edsger W. Dijkstra
Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity.
-- David Gelernter
Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.
-- Alan Perlis
Technical skill is mastery of complexity, while creativity is mastery of simplicity.
-- E. Christopher Zeeman
Architect: Someone who knows the difference between that which could be done and that which should be done.
-- Larry McVoy
One of the great enemies of design is when systems or objects become more complex than a person - or even a team of people - can keep in their heads. This is why software is generally beneath contempt.
-- Bran Ferren
A complex system that works is invariably found to have evolved from a simple system that worked.
-- John Gall
The most powerful designs are always the result of a continuous process of simplification and refinement.
-- Kevin Mullet
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
-- C.A.R. Hoare
Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
-- Antoine de Saint-Exupéry
Simple, clear purpose and principles give rise to complex intelligent behavior. Complex rules and regulations give rise to simple stupid behavior.
-- Dee Hock

This Brad's assessment of what "simplicity" means,

I think that true simplicity is about minimizing and managing overall complexity. Complexity in software design and development comes from the sheer size and complexity of the problem we are being asked to solve, and the richness and vastness of the interconnected maze of interactions within the system and between the system and its environment. The overall complexity of the system is dominated far more by the interactions between the parts that makeup the whole than it is by the parts alone. For any non-trivial system, simplicity often has less to do with the number and kind of different things involved and more to do with the number and kind of interdependencies between them. So achieving simplicity is less about managing "parts" of "things" or individual point-solutions, and is more about managing rules and relationships between the parts and things and solution-sets.

When dealing with large or complex systems (like most software, and software processes) the number of things (scale) and different types of things (diversity) that need to be managed is overwhelming. If we can come up with a modicum of modest, simple rules & principles to govern our design decisions in ways that help us minimize and manage interdependencies, eliminate constraints, and remove waste, then we are on the path to solving the real problem and meeting stakeholder needs in a way that is both simple and sustainable.

Framework Abuse - Dragos Manolescu

2006-05-31T13:00:00.000-07:00

Framework Abuse - Dragos Manolescu

I couldn't agree more with Drago's accessment on this subject. Problems that I have seen in the past were:
- People don't know the meaning of "framework", the best definition of framework is the one written by Prof. Ralph Johnson (one of the GoF). He wrote that, a framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact.

- From the misconceptual thinking of the framework, people tend to put "everything" in the framework, things that might not even be related.

- Rarely did I find framework with good referential implementation. As a result, either the consumer of the framework misuse it or doesn't even know such a feature exists.

- Frameworks were rarely updated, this of course can cause problems, since a stale framework might not serve the need of the consumer anymore down the line.

- Not enough "publication" or "evangelism" effort for the framework causing the framework to be abandoned.

- Not working together with the consumer causing people to develop frameworks that were hard to use, and didn't serve the consumer needs.

I'm sure there are a lot of things that I could have list here ...

ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal

2006-05-30T08:32:00.000-07:00

ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal

I couldn't agree more with Michael Feathers. Martin Fowler have discussed this in the past also. In his article he mentioned that there are two types of developers, the enabling one and the disabling one. An enabler, would probably be the type that would not restrict his code by introducing final excesively.

This is not to say that restriction is bad, because some restriction like private modifier is good for encapsulation.

Importance of error message

2006-05-29T13:31:00.000-07:00

On the weekend I was experiencing the problem in my .net code.

Here's a snippet of the code

System.Reflection.Assembly lib = System.Reflection.Assembly.LoadFrom("MyAssembly.dll");

object obj = lib.CreateInstance("MyType");

The obj instance turns out to be NULL, so I was really surprised, since I was able to find the MyType inside the MyAssembly.dll.

After spending hours of debugging, it turns out the "real" problem is, MyAssembly.dll depends on other assembly that I didn't include in the path.

Obviously any good developer should know, that returning a null doesn't really tell you or help you out, where as throwing exception with the exact information might. I would expect better code written especially for a Framework that's widely used.

Action vs. reaction

2006-05-19T10:32:00.000-07:00

In life we're always faced with a decision whether to react to something when it happens, or create a governance to prevent the thing to happen in the first place.

Pros and cons of reaction
- Reaction allow you to react on things, thus it gives you opportunity to come up with simple solution just enough to solve problems at hand.
- Sometimes it could cost a lot of money if we miss handled things that are critical to business operations.

Pros and cons of preventive action
- Preventive action is good to prevent things that we think might happen from happening based on our previous experience, etc.
- It can be overkill since every situation/environment is unique, and sometimes preventive actions introduced might not be suitable and it can be come overkill at worst. There's nothing more frustrating than come up with an overkill solution that slow down the process, and it will be even worse if people try to solve it by adding more preventive actions

My preference is to start with simple preventive action, based on the things that we know might break under common conditions, and react to any problems later when we face them.

Abstract vs. Interface

2006-05-09T12:41:00.000-07:00

Interface based programming has been around for a while, but yet, the adoption of it hasn't been widely accepted by most developers.

When people think of interface, they think of all the disadvantage of using it such as;
- adding new methods/changing existing methods to an interface forces implementer of the interfaces to have to implement the new methods too
- once interface is published it's thus set and we can only extend the interface by creating newer interface that will extend the old one

Although these are all valid points, but the benefit of using interface outweight the risks.

Some of the benefits are:
- Open and Close Principle
- Dependency Injection
- Interface Segregation Principle

As we all know from old principle that we usually use the interface more than we actually extend it ourselves.

One solution we could incorporate to ease the risk mentioned above (only if you need to extend the interface) is to always provide a base class together with the interface that we provide, thus user of the system has freedom to choose.

In most cases clients are only referring to the interfaces instead of extending them

Aggregate Component Pattern

2006-05-09T10:43:00.000-07:00

Microsoft Framework team introduces a pattern called "Aggregate Component" which has a similarity to a Facade pattern.

The purpose of this pattern is to enable user of the framework to only deal with one simple component to accomplish a particular task, ie. message queueing etc.

User of the API doesn't have to care about other components that have been encapsulated inside the "aggregate" component.

Some concerns of this approach are:
- It allows users to create object in inconsistent state, which can be remedied by throwing an exception when a user try to call the object with invalid state.
- The component settings need to be done in simple way, providing a lot of default value, otherwise, the benefit is reduced.
- It works well for entry level user, since, some of the default settings might not promote the most efficient way of using the framework.

Answering the "Where is the Proof That Agile Methods Work" Question

2006-05-08T08:54:00.000-07:00

Answering the "Where is the Proof That Agile Methods Work" Question

"Agilists don't write documentation"
This is further from the truth, although I agree that some of the "extremme" Agilist do ignore documentation. But that's not the point, the point is Agilist believes in DRY principle (www.agilemodeling.com/essays/singleSourceInformation.htm). Agilist actually have a lot more documentation, such as the unit tests, acceptance tests, and if the stakeholders are willing to pay, Agilist will definitely provide a high level overview, system models, user documentation, etc. The key is not to get lost in just providing documentations without a real software, and to always keep track of where the time/money goes in software development phase (sometimes documentation time is not tracked)

"Agile teams don't need project managers, quality assurance people or architects"
This is only half true, Agilist support the notion of "Object should be specialist, and Developer should be generalist", member of Agile team should be able to wear multiple hats. Every one should be part of ensuring the quality of the system, and design is more of a collaborated effort than something bestow by an ivory tower architect team. (www.agilemodeling.com/essays/agile Architecture.htm)

"Agile cost-of-change curve is flat"
This is supported by the fact that Agile methodologies adopt short iterative cycle releases, thus any problems should be detected sooner and client feedback is a must in every iteration leading up to the release. (www.agilemodeling.com/essays/costOfChange.htm) The key to agile success is always feedback and the sooner we get the feedback of the system the better chance we have for the success. Feedback comes from the developer to proof that his/her idea works, from the tester, from the client. (www.ambysoft.com/essays/whyAgile WorksFeedback.htm)

Reference

Crossing the Chasm, Scott W. Ambler, SDMagazine May 2006

Project 911

2006-05-08T08:28:00.000-07:00

The three most common questions asked by your boss/client before you undertake a project are;

1. Can you do it?
2. When can you do it?
3. How much it will cost me?

These questions are hard to answer because there are different obstacles facing a project during its lifetime, such as;
1. Change is sometimes inevitable
2. How can we handle the unknown?
3. Can we get commitment and clear direction from all stakeholders?

In order to ensure that a project will be on track, we must:
1. Assemble the right project team, people on the team should have a good working harmony
2. Have support from all stakeholders
3. Ability to control the scope, decide which one is a must have or nice to have, and capture nice to have for later release
4. Must have iterative releases, since it will give the stakeholders a sense of progress and opportunity to provide feedback
5. Must have active client involvment

Reference

Project 911, Donna L.Davis, SD Magazine May 2006

The need for public method vs. published method

2006-04-13T18:58:00.000-07:00

A public method is relying on a language syntax to make it public, usually a concrete class that contains public method will
mark its methods signature with a "public" keyword.

A published method is relying on a language interface to make it published. Usually a concrete class will implement some interfaces
that will contain methods, and in it is a contract that the particular class will abide.

The need for published method arise when different client will be exposed to different "public" method, ie. instead of exposing the
concrete class, we're only exposing certain methods to the client based on what the client "need" or allowed to access. When design
correctly published methods in interfaces can decouple client with concrete implementation of the class while supporting the Open Close
Principle.

For example, when using class to just expose its data for setter/getter to a client front end, to be mapped to user fields, the creator
of the class doesn't need to make other state changing methods that would otherwise be called by the layer where it isn't supposed to. Thus
exposing only the interface for getter/setter to the presentation layer, will prevent client on the layer to perform any business logic that
would have to be done in the other layer.

This idea was introduced by Robert Martin in his Seggregated Interface Pattern. The pattern was created to support the idea that different clients
will have their own need and concerns, thus they don't have to / shouldn't be exposed to just "one" interface, ie. the concrete implementation of
the class.

Why big upfront design will never work.

2006-04-05T09:17:00.000-07:00

- According to McConnell, design effort consume about 75% of the whole development effort, thus investing that much time without proving that it works
make the whole effort very risky
- design with UML can't be verified, the best we can do is peer review, but without automated verification tool, and relying on human effort also increase
the risk of design correctness, esp. since design is largest effort in the whole software development
- nature of human being is to work best when dealing with multiple smaller things instead of big thing at once in order to lower the risk of incorrectness
- unpredictable requirements due to designer understanding of the problems to be solved, the analyst effort of their gathered requirements, the customer
needs of what he/she wants are not perfect from the get go. Business also evolves what's good now might not be good in the future

This doesn't mean that there isn't a case where big upfront design can be made to work, such case where it can work are as follows:
- software migration development in which all requirements are solid and will not change, assuming the analyst, customer and development team had worked
with previous product that needs to be migrated
- governmental type of project where they could afford to spend a lot of money and a lot of time and also be able to absorb any losses necessary, think about
big weapons or airplane project that had cost billions of dollars but were never used

The best thing is to be able to recognize how agile we can be, or how much plan do we need to have without stranglehold the development process and become
inefficient. How agile measure sucesful project is by how much business value the system adds for the customer, while also keeping the cost and budget
reasonable.

"A late change in requirements is a competitive advantage" - Mary Poppendieck

The Joel on Software Discussion Group - Why I Hate Frameworks

2006-03-20T13:17:00.000-08:00

The Joel on Software Discussion Group - Why I Hate Frameworks

The problems with building framework are you can't satisfy all the requirements required by all stakeholders. Good frameworks will have these characteristics:

- It has to be reusable without over-engineered the framework. Start small and let it grow, only implement things that are needed by common team without the extra bells and whistles.
- Good framework team should solicit feedback from the clients (user of the framework) and provide only necessarily extensions per request
- Good framework should provide documentations and samples for easy usage
- Good framework should provide well defined extensions point and don't expose things that aren't suppose to be extended. This practice will prevent
- misuse of frameworks that can cause performance issues
- misuse of frameworks that made it harder for user to upgrade it in the future

How to scale Agile Methodology?

2006-03-15T13:32:00.000-08:00

There are different techniques you could use to make agile methodology work for large organization, and the key to it all is "Divide and Conquer".

A few tips you could do are as follows:
- create multiple sub-teams, each working on separate sub-systems
- have a well-defined interfaces that different systems are communicating with
- all project teams involved must support the methodology
- have a small design session to hash out high level architecture
- have daily status meeting b/w representative of each team in addition to within the team itself

SOA vs. ESB

2006-03-15T13:12:00.000-08:00

ESB approach has become more favorable in comparison to SOA these days. Some of the supporters arguments about the benefits of ESB are as follows:
- it decouples the client interactions to the source systems
- it will maintain the data mapping, transformation and translation internally thus freeing each sub-system from those responsibilities

However ESB also posts the following challenges:
- it hides the spaghetti interaction inside its blackbox
- it can further erodes and turn into another point of integration due to the following cases:
- organizational decision to get things done quickly
- performance or optimization to bypass the ESB layer
- law of entrophy
- it's not easily customizable according to individuals client needs

A few benefits of SOA are:
- it still provide loose coupling
- it's quicker response time as far as having another "team" to do it
- interfaces can be customized to individuals application needs
- different SLA can be applied to different interfaces
- it's easier to change interfaces b/c you don't need to worry about affecting other
client's system

SOA approach however is not without its short coming either:
- it can potentially creates duplication of logic as different systems will be connected directly
- number of services created can go exponentially large and harder to keep tracks of

In order to make SOA more favorable, we need to consider the following
- it's good to have inventory of all SOA services
- you can always refactor the SOA services that could go together to a new SOA service thus it will encapsulate the services interactions
- versioning problem can be handled by the following
- treat data transfered as document centric
- if there's a need to maintain backward compatibility, set an expiration date on previous versions
- mark the SOA message with version number, and try to keep away from maintaining a lot of versions
- sometimes it's better to provide SOA service specifics to clients need and only consider reuse if it's actually reusable, b/c afterall reusablity is not free

Agile Legacies: Using Iterative Methods to Import Legacy Data

2006-03-08T09:36:00.000-08:00

java.net: Agile Legacies: Using Iterative Methods to Import Legacy Data

I agree wholeheartedly in this article, the impacts of not doing iterative legacy data import are as follows:
- some fields were missed/not mapped in the development
- missing features are detected very late
- fields are not one to one translation to the new domain, thus domain needs to be changed

Benefits of doing iterative data migration:
- migrating data at the same time as development can improve the system by uncovering things that don't work well in the old system
- developer works with more realistic data

Challenges of doing iterative data migration:
- DBA needs to buy into the process
- Data needs to be scriptable so that unit testing can be accomodated
- Analysis work needs to be done early for data migration
- Domain model needs to be work on together with Data analysts and DBAs

The importance of SLA

2006-03-03T07:20:00.000-08:00

Service Level agreement set the standards/requirements of the system in a concrete manner. Thus there won't be any
ambiguous requirement down the line pertaining the system under development. What SLA should cover are as follows:
- availability concerns
- uptime (system needs to be available this % of time) /downtime (for maintenance)
- scalability concerns
- how many concurrent users can it handle, CPU, Memory
- performance concerns
- response times

SLA written needs to be reasonable instead of some wishful thinking, since it could affect budget cost/time for
something that users rarely need. It is sometimes useful to use stress test even in early release cycle

To Distribute or Not to distribute

2006-03-03T07:19:00.000-08:00

There are different methods of achieving distribute communication:
- web service
- rpc
- http

Reason to have distributed system:
- the need to create separate system (sold separately)
- smart client with centralized application server model
- integration with another organization
- integration with COTS products
- integration with legacy application that has legacy technology/architecture
- different systems have different availability/up time requirement

Not a reason to distribute

- api is getting complex, to achieve coarse grained access
- different release cycle
- clustering
- organization breakdown

Cost of distribute environment
- increase in complexities for transaction management, security, error handling
- need business process management to manage process flow amongst participant system

SOA vs. Point to Point Integration Arch.

2006-01-18T21:00:00.000-08:00

SOA approach

- different application communicate through the canonical model
- benefit of such approach are:
* different systems can use the same service
* less work need to be done in the adapter layer
* more reusable services

Point to Point approach

- different applications will need different service call to the integration layer
- benefit of such approach are:
* application and integration are decoupled from changes in the domain
* application and integration team can work independently

Thoughts on Software & Integration Architecture from the Trenches: Agile Development and Architecture - Yeah Right!

2005-12-07T13:16:00.000-08:00

http://blogs.ittoolbox.com/eai/trenches/archives/006787.asp

I'm somewhat agree with the author as far as what are bad things that could happen when Agile practices are not done correctly. Like any other practices, RUP, XP, RAD, things could go wrong regardless of how well/matured the particular practice is.

"Speed" is not the main goal of Agile development practice, it's one of the many side effects that come from it, like many other efficiently run practices (RUP or RAD).

Agile practices support delivering what's most important to the users of the system/stakeholders(could be users, architects, project sponsor, etc.)

Things that Agile practices have done that resulted in faster time delivery:

1. Only implement what the requirement stated, with no added bell and whistles that deliver the least amount of value but it still take time to produce.

This doesn't necessary mean Agile practioners abandon common senses/good practices, b/c by doing that it will also cause negative effects in the future and thus cause major rework which essentially will impede the "speed".

2. Agile practice encourage constant refactoring

This doesn't mean that Agile practioners do things badly in the first place without thinking and fix it later, I hate to admit but bad people usually does this, but regardless of how good a practice is, bad people will always exists, we can't control that.

Refactoring is done to improve the code, readability, make it easier to maintain in the future, because software are flexible, in my experience , you can't possibly write a piece of software and get it right at the first cut. (even Beethoven couldn't do it, unless you're Mozart) As things changes, and development team learn new thing/technology, its to developer good conscience to apply his newly found knowledge to the codebase rather than leaving it the way it is.

3. Creating a good testable code with loosely coupled and high cohesion is also goals for every agile practioners

the way to achieve this is you're applying Test Driven Development in your coding practice, you'll write your test to improve your design, afterall each component that you create will be use by some other component, and it only make sense that your test component be the first one that use your component, because you'd rather find out that your design make sense earlier rather than later on once things are harder to control/fix.

this practice allows you to have faster feedback as far as how good your design really is, again "speed" is the result of other good practice not the ultimate goal of it.

The author mentioned as an example things about enforcing database constraint, these are a common sense, and should be part of other non functional requirements of system under development.

One should allocate/treat these non functional requirements the same way as the other business requirements, which I admit is a bit harder, since business stakeholders don't care (directly) about these non functional requirements, however, architects and other people in an organization are also stakeholders, and their needs should be fulfilled, and works should also be budgetted against that requirements.

Like other software practices, sometimes development team will miss estimate on these non-functional requirements, which are a shame, and should be corrected and included as part of work and budget when building a system.

But one thing for sure there should be tradeoff made on these non functional requirements also, the same as business requirements, because the last thing people want is to spend years on development handling these requirements trying to make the system perfect and missing the actual intention of creating the system in the first place.

Does client list matter?

2005-11-16T05:21:00.000-08:00

We've seen over and over again, companies boasted their clientele list on their website (products or services companies). But the real story is, are those clients happy with their works?

One of Agile's methodologies is to deliver highest values to the client. But that again is only half the story. Features might be delivered to what client's want, but there are a lot of other software qualities beside just features (features are not qualities by the way)

And in order to satisfy the other qualities, we have to realize that as part of our deliverables or user stories (according to XP)

Inflated requirements

2005-09-22T21:32:00.000-07:00

The concept of small increments iterations in a project allows a project team build the system incrementally in small chunks. This in turn allows user to see the system and be able to react to it or give feedback much faster than traditional waterfall method.

There's a "process smell" in iterative world today, where a requirement/user story starts out small but keep increasing in the number of success scenario thus affecting the original estimate of story. This sort of activities seems harmless at first, since they changed a little at a time, but could potentially grow infiinitely.

And it left poor developers scrambling and changing their work b//c of this constant changes, thus leaving it up to the project manager or the technical lead on the team to voice the concerns and stop the activity to become the norm.

There's nothing worse for developers morale than to see his/her story is never completed due to constant additional changes to their work.

This activity also relates to piling on multiple defects into one defect filing which will have the same consequences for the development team

Hibernate Session is not the same as Unit Of Work

2005-09-15T19:44:00.000-07:00

A Unit of work usually defined operation(s) that will be executed within a single transaction to preserve
the ACID rule. Hibernate session however could be tie in with a request (ie. web request) since there's no
guarantee to preserver a session to be executed within a single transaction.

Martin Fowler's definition of UnitOfWork is exactly that
http://www.martinfowler.com/eaaCatalog/unitOfWork.html

"A Unit of Work keeps track of everything you do during a business transaction that can affect the database. "

AOP vs. Observer Pattern

2005-08-29T13:45:00.000-07:00

Aspect:

PROS:
- encapsulate changes in one place
- faster development time
- declarative programming
- crosscutting problems are solved
- compiler support
- debugging can be done like normal code with proper IDE

CONS:
- easily abused
- harder to follow
- required learning curve
- harder to maintain

Observer Pattern

PROS:
- easy to debug
- more obvious in domain where changes happen

CONS:
- creates more coupling to domains
- easier to introduce defects, since changes are done in multiple places
- needs to create framework
- runtime debug

Database Coupling == Root of all evil

2005-08-25T12:30:00.000-07:00

The hardest coupling to deal with is database coupling for various reasons:

- it spans more than one system, a lot of time including legacy applications
- it spans more than one development group, creating organizational related issues
- it deals with enterprise data, make it that much harder to change, as data is less flexible than code for example.

as the result, people usually just accepted the fact of it and do nothing to ease the problem. notice i said ease, b/c
database coupling like any other coupling can't be eliminated fully. Like its counterpart, the code, database coupling
can be reduced by introducing encapsulation with another layer of indirection (the cure for most computer science problems)

Why business fields shouldn't be used as primary keys?

2005-08-22T10:03:00.000-07:00

When designing a database entity, it's preferable not to business related field to be the primary key of an entity. For example,
if we have a Customer entity, we should consider not to have SocialSecurityNumber as the primary key, but to create a CustomerNumber
as the primary key(surrogate key). This practice enables separation between business type field and database type field for a number
of benefits:
- hides database key from business users
- guarantee uniqueness of an entity within the database system
- promotes more flexibililty to the design ( ie. in the case of Customer, not everyone has SSN )
- it's more natural and simple ( ie. Address with AddressId as its primary key, instead of address name, city, state, zipcode, etc. )
- decouple business changes from db changes ( ie. changes related to business key, will force foreign key changes )

However, application should still query the business entities by its business key, afterall business logic shouldn't aware of the
existence of db key (thus decoupling the two)

What is Consulting?

2005-08-17T12:31:00.000-07:00

What is Consulting?

Sometimes I disagree with Bruce in a few of his technical approach, but I agree wholeheartedly on his view.

The most important points to be a succesful consultant are:

- teach the client, and hopefully you are a good teacher and be able to leave the client at a specified finite time. (not infinite time)
- communication is the most important part of consultancy
- continuosly upgrading your skills so that you feel the pain first before your client feels it
- have a good network -> gives you future opportunity easier without having to hog down one client for extended period of time

The different about body shop work and consultancy:
- body shop usually doesn't have much says in technical decision being made by the clients
- body shop is not obligated to teach the client
- body shop should be cheaper
- body shop work can be done offshored

How to implement P of EAA: Data Mapper in Hibernate?

2005-08-04T07:46:00.000-07:00

P of EAA: Data Mapper

Hibernate provides custom user type capability in UserType or CompositeUserType. Those classes provide
capability to map user domain type to database type, including any conversion that needs to happen. Other techniques involve querying data from other external resources such as LDAP, etc. thus frees up domain responsibilites from other non domain related concerns.

Also, in the spirit of Domain Driven Design, where domain sometimes relies on other external resources that will impact its properties, one can use this pattern during loading/saving of those properties cleanly

Importance of messaging in distributed environment

2005-07-26T13:03:00.000-07:00

Messaging is the Right Way to Build a Distributed System

I couldn't agree more with this article. Messaging should also be considered in applications where there are many subsystems in order to prevent "point to point communications hell". For example, in a CRM system where it contains HR, Accounting, Sales, etc. they should be communicated with each other using messaging, and service oriented approach.

Why do we need to keep actual?

2005-07-26T08:31:00.000-07:00

in software engineering fields, estimates are usually done in the beginning of a project/release cycle. some estimates are good others are usually
bad (see how to do good estimates?)
based on those estimates, sometimes it takes more or less for development team to complete the tasks. the importants of keeping the adjusted/actual
effort (in terms of hours preferably) to complete the tasks are as follows

- it makes good resources for future development estimation ( near or distance future )
- good for making cases for late project causes ( aggresive estimates number are most of the time the cause of late project )
- track the real costs of the project ( although this number can sometimes derive from timekeeping, but a lot of times time keeping numbers are not
well represented, ie. ppl don't usually separates their actual effort to this project with other daily activities)

Code smells

2005-07-21T16:16:00.000-07:00

Below is my code smells snippet of the day

public class RequestCycle implements IRequestCycle {

public void renderPage(...) {
page.renderPage(..., this);
}

public void commitPageChanges() { ... }
}

public class Page {
public void renderPage(..., IRequestCycle) {
....
this.commitPageChanges();
}
}

okay ... so we just b/c we introduce IRequestCycle doesn't mean that this code doesn't smell.

why would a class call other class and have that other class callback to another method in the originating class, especially at the end of the called method.

this is another sample of unnecessarily tight coupling introduce in a somewhat wellknown framework

What makes a good framework

2005-07-20T21:22:00.000-07:00

There are a few criteria to identify a world class framework

1. don't expose the public interface unless you expect the user of the framework to overload it
2. force everything that should be overloaded to be an abstract method
3. Leverage template method pattern to support point #2
4. make classes and methods final if you don't want developers to overload it
5. document all of the extension points
6. document the execution flow of the framework if exists

any other thought?

I hate super.xxxx()

2005-07-19T08:42:00.000-07:00

i hate an overridable methods that force you to call its super method. OK beside the fact that inheritance is not encouragable, but to force the implementer of the subclass to know what's going on in the super class creates an even tighter coupling b/w subclass and its parent class

this problem is even more magnified when you're dealing with frameworks. Allowing the user of a framework to override method and calling its super method is going to be more problematic, since the implementer of the method couldn't modify the method at will due to unexpected side effects.

so what could good framework developers do .. see this
What makes a good framework

Josh Bloch on Design

2005-07-15T11:33:00.000-07:00

Josh Bloch on Design

A few things that I agree from Josh Bloch comments

- XP says "Do the simplest feature set that could possibly work, without overdesign, and extraneous bells and whistles" but do not "Do the quickest slop you can thrown down that could work possibly", which will suffer in the long run

A few things that I disagree

- API design is not the same as other non-API design, it requires much more effort and cost. Creating reusable components are much more expensive than especially if we're talking about community used API (ie. Java SDK, and so on) And to spend that much effort if we don't know for sure that the API's going to be use widely would be a waste. Afterall, components are not really reusable until it has been reuse multiple times. However, this doesn't mean that we would not have reusable objects within the System Under Development, constant refactoring by removing duplicates will promote it by itself, without the cost of trying to come up with a silver bullet API

Grouping packages based on specific patterns

2005-07-15T09:49:00.000-07:00

Should one want to name a package based on a specific pattern name? For example, is it a good idea to collect all of the factories classes into one package. On the surface it looks like it's ok to group them by pattern, but if one of the rule of putting things in one package is to achieve high cohesiveness between classes in a package and to reduce coupling between other packages, then this idea is definitely not very sound.

Any other thought?

Interface Segregation

2005-07-14T19:36:00.000-07:00

Should interfaces be separated into separate package than their concrete implementation?

I think a more important approach is the benefit of those separations. I believe that separating interface and its concrete implementation just by namespace/package but still deploying it into the same deployment package (jar or dll) then we lose a little bit of those benefits.

I would lean toward separating interface and implementation to two separate deployment package. They could have the same package/namespace name which doesn't really affect the intention of separating it.

For details on interface separation, please refer to "Interface Segregation Principle" pattern discussed in Robert Martin's book (Agile Software Development ...)