Three Cornerstones of Business Software

Processes

Business rules

Information

User Experience (UX)

User Experience (UX) design team: Hopefully UX design is a core deliverable and not something we leave to the developers to handle. UX design is sadly overlooked and should definitely have a status elevation. It is important to have close collaboration between the UX team (which could be just one person) and the development team. The best solution is obviously to have a UX expert in the development team all through the project, but that is sometimes not possible. The UX design is so important in making sure users can really perceive the value of the system. We can write the best business logic in the world, but if the UX is badly designed, the users will probably never think the system is any good.

Three Pillars of Application Lifecycle Management

Traceability,

Processes Automation

Visibility

on site architect for a construction project

Imagining you are the onsite architect for a construction project.

When you found the construction company cutting cost by lower the mixing ratio for the concrete or choosing lower cost material or lower the usage of certain material, or reduce the waiting time for the concrete to dry, but you realize that you do not have veto power and all you can do is “lead by influence”, will you be comfortable to be responsible for the quality of the building ?

achieve your goal by letting it go

In Christianity, there is something like "seek His glory; the rest will be given to you". I would like to parallel phrase‎ it in software development "Seek quality, the rest will be given to you". those who sacrifice quality for the interest of time will lose both.  However, good quality does not necessarily mean cost more time, or over engineering. It means all of design decisions, architectural decisions or programming decisions are well thought for and based of requirements or best practices.

Good project management + Good architectural design + good engineering process = good software product.  Once a good architectural design is in place, mindset of the project management is the key to its success.

The chef determines how good the banquet can be

A chef would not present a dish if he is not comfort with the cooking of the dish;

An architect would not include an architectural structure in his design if he is not knowledgeable on the architectural structure;

A project manager would not endorse any SDLC process, if he is not comfortable

A programmer would not adventure with certain programming technic if he is not familiar with the technic.

Unless you are in the driver seat, you only can influence the decision making; you are not the decision maker no matter how good you are in these technical areas.     

Tailor Ed and his 3 sons - Continue

6 months passed. 3 brother’s busy working on the suit. They busy designing the tailor machine, using the tailor machine, busy sewing using the sewing machine….  The team spent lots of late nights and working weekends.

One day, I chat with Bobby about his project; I was told the new suit is “same crap different suit”. “We left the sewing team mostly the same in terms of skill, training, communication, etc. and leadership hasn't gotten any wiser, so the output shouldn't be expected to be much better than before”. Bobby agreed with me on the statement “if we continue let the project go like that, we would end up at the same boat as we had” by saying “yep, that's where we're headed.“


Link

Naming is the source of most confusion

If you take the source code of working software and rename all the variables, methods, properties, classes to something meaningless (something like A1, A2, B1 B2 and so on) and rebuild it, you will find it works as it did before. To the compiler, the naming makes no difference.

However, to programmers it makes a huge different. It would be a nightmare to work on the source code with meaningless identifies.  

Martin Fowler was quoted in book of “Microsoft .NET: Architecting Applications for the Enterprise”, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” I would like to follow-up by saying “when it comes to readability of the code, naming is the source of most confusion and only the program that can be understood by human can be accepted as commercial software.”

Make handymen to build a house

A home builder is hiring some more workers for his new construction project. A few handymen, applied for the job.

When he interviews the candidates, he asks the following questions:

1)      Do you know how to use hammer?

2)      Do you know how to use saw?

3)      Do you know how to use measurement tape?

4)      Do you know how to use power tools?

When he gets positive answers, he hired them.

Not long after the project started, he realized the project is not doing well, the wall is not straight, and the floor is not level…

A software company is hiring some software programmers for an enterprise commercial system. A few non-professional programmers came to apply for the job.

When he interviews the candidates, he asks the following questions:

1)      Do you know how to write VB.Net program?

2)      Do you know how to write SQL/Server Stored procedure?

3)      Have you created sql server tables and views?

When it gets positive answers, the company hired them.

Not long after the project started, he realized the project is not doing well, the design of the system is convoluted, the code is difficult to read and full of bugs, when one bug is fixed 3 other bugs are produced, the performance of the system is terrible, the project is way behind schedule…

The commonality between above 2 scenarios is the decision maker mistakenly confused tools over skills.

Lots of people know how to use a specific language write, but not all of them can write beautiful novel or a scientific paper; lots of people know how to play piano, but not all of them can play beautiful music like pianist ; lots of people know how to use these tools a professional home builder uses, but not all of them have the skills to build a single family house; lots of people knows how to write .Net code,  and design database tables, but not all of them are qualify to design / develop commercial standard enterprise software system. It is the skillset differentiate professionals from non-professionals not the tool.

when you have a hammer in your hand, everything looks like nail to you

A few years ago, when I joined a company as the Application Development Manager, I found some specific technologies were widely used there. “Open query from SQL server to access Oracle database data” is a typical case.  They use open query in SQL/Sever to update, insert and of course, get data in Oracle database. In the way, this is the standard way for them to access Oracle database, even when there is no need to integrate data from SQL/Server database.

First of all, it is difficult to maintain, when you issue a select statement in SQL/Server, it is hard to imagine that in fact you are updating some data in Oracle.

Secondly, it created some point of failure unnecessarily. If SQL Server is dead, your application will not be available, even if there is no need to access SQL/Server data.

Thirdly, the power of PL/SQL is not unleashed.

Finally, the performance of the application is comprised. All data need to go through 2 hops back and forth.

With that, I started to implement a new architecture for these applications.

With the new architecture, I had stored procedures in the form of packages created directly in Oracle database and had a DAO Layer developed to access Oracle database calling these stored procedures via Database Application Block.

It was a big success. Slowly, this new architecture had been accepted as a standard way of accessing Oracle database. “Open Query” from via SQL/Server database been slowly faced out…

One day, I had lunch with one of the developers.  During the lunch, when we talk about technologies, he said “Peter, when you have a hammer in your hand, everything looks like nail to you.”

Yes, that’s it! If in your tool box, hammer is the only tool you have, you will try to use it as long as it works. it does not matter if hammer is the best tool for the job or not.

As an architect, in order to design a system with all best practices, you need to enrich your tool box. First you need to know all kind of tools available in the market well, and then you need to know when to use what tool. Use a specific tool for the sake of using it is one of the infamous antipatterns. Use a specific tool because that is the only tool you are comfort with is equally bad. 

Miranda Warning for programmer

You have the right not to be a programmer. If You choose to be a programmer, every line of code you put in (even if you copy / paste from somewhere else) can be and will be used against you in debugging session or code review session. Or even worse, they will be used in the root cause analysis of a production outage. Be prepared to stand by them.

Vision and strategy for software product development team as application development manager / chief architect

Vision:

·       The company gets the envisioned software product developed with a strong, energetic and vibrant team.

·       The individuals get opportunities to further develop themselves professional with strong commitment from the leadership.

·       The team not only capable of fulfilling its duties today, it is also well prepared to fulfill its duties tomorrow.

·       The relationship among the leadership, the management and individuals are healthy and constructive.

       

Strategy:

·       People first, then project

·       Business first, then technologies

·       Think Win-win (All are in for winning, and all are winners)

·       Seek first to understand, and then be understood

·       Balance between product and production capacity

·       Balance between short term deliverables and long term deliverables

role of Manager / Chief Architect

·       Coordinator / facilitator: provide technical leadership by being coordinator / facilitator for the team. Develop solutions by working with the team.

·       Partner: be the partner for LOBs in their business operation and new business development; be the partner for team members in their professional career development.

·       Communicator: Seek first to understand, and then be understood. Establish common understandings and common goals

·       Supporter: provide technical support to the leadership; provide management support to the team.

• Professional development

·       Provide resource: 


o       MSDN Subscription


o       Online book library ( books 24 by 7)


·       Promote learning and sharing


o       Encourage pursuing MS certifications (MCP, MCTS etc.)


o       Presentation / demo on new technologies


o       Establish digital asset library for reusable parts ( demo, POC, component)


·       Promote collaboration


o       SharePoint site


o       Shared library


o       Wiki library


o       Email, Skype, IM, Phone


·       Focus on professional development with personal touch


o       Regular 1-1 meeting


o       Develop career development plan with team members


o       360 degree Reward system (salary adjustment, promotion, bonus, award, opportunity, training and seminar) 

The 7 habits of highly effective people

·       Be proactive

·       Begin with end in mind

·       Put first thing first

·       Think win-win

·       Seek first to understand, and then be understood

·       Synergize

·       Sharpen the saw

UI Design Patterns

Option 1: (without testability)

MVP

Application Controller

1. Each form has its own controller
2. Controller interact with its form via its public interface (property, event, methods)
3. For forms, other than the public interface (property, event, methods), everything else is private. (not accessible by its own controller)
4. User Controls do not have its own controller. Hosting form interact with its user controls via  public interface of the controls (property, event, methods)
5. User controls is private to hosting form, the controller of the form does not have the knowledge of the user controls it hosts.
6. Forms has no knowledge of their respective controller
7. For each business process (each transaction), there is a Business Process Controller.  BPC complete its process by interact with public interface of Controllers.

Benefits

1. “Separation of Concerns” leads to cleaner code and easy to maintain.
2. Reusability on User Controls
3. Reusability on forms / controllers

Option 2 (with testability)

1. Each form has its own Presenter. Each form implement a specific interface (e.g IMyForm and MyForm)
2. Presenter interact with its form via the interface the form is implemented
3. For forms, other than the implementation of the interface, everything else is private. (not accessible by its own controller)
4. User Controls do not have its own Presenter. Hosting form (or control)  interact with its user controls via  public interface of the controls (property, event, methods)
5. User controls is private to hosting form, the Presenter of the form does not have the knowledge of the user controls it hosts.
6. Forms has no knowledge of their respective Presenter
7. Each Presenter implement a specific interface IPresenter
8. For each business process (each transaction), there is a Business Process Controller.  BPC complete its process by interact with the interface of the Presenters.

Benefits

1. Separation of Concerns, cleaner code, easy to maintain
2. Reusability of user controls
3. Reusability of Presenters / forms
4. Testability on Presenters
5. Testability on Business Process Controller

Option 3 (with testability on user control logic)

1. With everything described in option 2
2. Make a presenter for each user control,
3. Make user control implement its own interface (MyControl implements IMyControl)
4. My the presenter of the user control interact with user controls via its interface

Additional benefits:

        The user process logic for user controls is also unit testable.

Visual Studio 2012

1.       Supported OS:

a.       Window 7 ( 32/ 64)

b.      Window 8 ( 32 / 64)

3. Windows Server 2008 R2 (x64)

d.      Windows Server 2008 R2 (x64)

2.       Support .Net framework : 4.5

3.       Component inventory

a.       Visual Studio Agent 11

b.      Visual Studio Team Foundation Server 11

c.       Visual Studio Team Explorer Everywhere 11

d.      Visual Studio 11 Remote Debugger

4.       What's New for Visual C# in Visual Studio 11 

a.       Asynchronous Programming with Async and Await (C# and Visual Basic)

UI design pattern and UI design elements

Design patterns

1.       Terms

a.       Public interface: public methods, public properties and public events.

b.      Host of the control: the form or the user control where the user control lives.

2.       Patterns employed

a.       Model-View-Presenter(Controllers)

b.      Application Controller

3.       Various classes / objects

a.       User Controls

b.      Forms

c.       Controllers

d.      Process Controllers

e.      ViewModels

f.        Interface for Controls, (IPrerequisiteView)

4.       Relationship

a.       Each Presenter has a form to be its visual representation for human-computer interfacing.

b.      Each form has a controller to be its public interface for  API interfacing

c.       User controls do not have Presenter.

d.      The user control has its own visual representation for human-computer interfacing and public interface for API interfacing

e.      Controllers interact with WCF service to complete its business operations.

f.        Each Process Controller instantiate and communicate with various controllers to complete its functionality.

g.       ViewModel act as entity object model participate in the definition of various public interfaces. (As the type of the public property, as the type of the parameter or return value of the public method, or as the type of the argument of the events.

5.       User Control

a.       User control has a defined public interface. Everything else is private.

b.      User control has no knowledge of its host.

c.       User control communicates with its host via its public events and public properties.

d.      The host manipulates its user controls via the public methods, public properties of the user controls and response to public events of the user controls.

e.      User control instances shall be defined as private members inside its host.

6.       Form

a.       Form has a defined public interface. Everything else is private.

b.      Form has no knowledge of its controller.

c.       Form communicates with its controller via its public events and public properties.

d.      The controller manipulates the form via the public methods, public properties of the form and response to public events of the form.

e.      Form instance shall be defined as private member within the controller.

7.       Controller

a.       Controller has a defined public interface. Everything else is private.

b.      Controller has no knowledge of its any Process Controllers that it is in.

c.       Controller communicates with its Process Controllers via its public events and public properties.

d.      The Process Controller manipulates the Controller via the public interface of the controller.

e.      Controller instance shall be defined as private within Process Controller.

8.       Reusability

a.       The same controller/form combination can be used in different Business process

b.      The same user controls can be hosted in different form and/or different user controls.

9.       Testability

a.       We can inject an implementation of the public interface of the form to test controller.

b.      We can inject an implementation of the public interface of the controller to test Process controller.

UI Design elements

1.       Views: ( forms and user controls)

a.       Some write up on the view, what is the main functionality

b.      Visual representation for the view.

c.       What other views to be used in this view

d.      The public interface (public properties, public methods, public events) and their purpose.

2.       Controllers

a.       Which view it is controlling (maybe through naming standard). Some write up about the functionality.

b.      Public interface of the controller (public properties, public methods, public events) and their purpose.

c.       How it is used…

d.      What kind of service operation it needs from WCF services

Technical Debt

The "technical debt" metaphor was created by Ward Cunningham as a way to understand and track the intentional and unintentional design and coding shortcomings of software.

We take on technical debt when we oversimplify a design or recklessly create a flawed design.

We take on technical debt when we wisely or unwisely write code that does not work as well as it should.

Taking this metaphor from the financial world, debt is one of the ways to finance an organization.

It can provide the cash needed to make payroll. It provides the organization an opportunity to buy things like furniture and equipment. If the payments on interest and principal are well managed then the organization can properly handle the costs of financial debt.

The same is true for technical debt. With technical debt, the "interest payments" are the added effort and frustration caused by the inadequacies of the current design and source code. In this metaphor, the "principal payments" are the effort needed to go back and remediate or improve the design and source code.

From “Pro .NET Best Practices”

Project Managment

·       Scope management

·       Schedule Management

·       Budget Management

·       Quality Management

·       Resource Management

·       Risk Management

·       Issue Management

·       Procurements Management

·       Process Management

Separation of Concerns

Cohesion measurement ranges from low to high and is preferably in the highest range possible.

Coupling measurement ranges from low to high and the lowest possible range is preferable.

…

A principle that is helpful to achieving high cohesion and low coupling is separation of concerns (SoC).

From "Microsoft .NET: Architecting Applications for the Enterprise"

Programming is a matter of state of mind

Many years ago, a senior programmer once said to me something like “to be a good programmer, you need to have 2 characteristic, one is logical thinking, another one is common sense.”

 

In my code review process, when I pointed out that update logic should not be in a “CREATE” stored procedure (USP_CREATE_INDIVIDUAL_ADDRESSES with the comment saying: This SP creates collection of records in XXX Table)

 

When I pointed out that some code like following does not make sense:

IF(@I_CUSTOMER_ID = 0)

      SET @I_CUSTOMER_ID =0

IF(@I_INDIVIDUAL_ID = 0)

SET @I_INDIVIDUAL_ID = 0

The responses I got were something like: okay, we will rename it; okay, we will take these code blocks out. As if these are not big deals, it was just me being picky.

To me, these are big deals to any programmer.  For sure, we programmers write program with bugs, I have my fair share of bugs in the code I wrote. In most of time, the bugs are introduced by we forgot to handle certain scenario, or we missed a piece of business logic.  That’s fine, because we are human. From time to time, human tend to forget things or overlook things.

It is not fine when we programmer write code without logic thinking, without common sense. At any point of time when we write program, our state of mind need to be very clear on what we want to do and how we do it. When a programmer wrote some code like the code block above, what was his or her state of mind when he or she hit the keyboard? When a programmer decided to extend the scope of the stored procedure from “Create” to “Update” without renaming or added comment indicating so, did that come across to his or her mind that it would create confusion for the fellow team members? What was his thinking process when he or she hit the keyboard put these code blocks in?
 

If these coding practices came from the same programmer or the same team, how confident you are on other code written by them?

Martin Fowler once said “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” I figured that’s because we human read the program with the goal of figuring out what it try to do with logical thinking and common sense, while computer reads the program with the goal to do what it is instructed to do even it does not make sense. Like people use natural language communicates with people around them, programmers use programming language to communicate their thinking with fellow programmers.  Through listening to what a person say, we get to understand one’s state of mind; through reading the program a programmer wrote, we also get to understand one state of mind. To any programmer, State of Mind matters the most!   

Fix what's wrong

The second consecutive week of overtime on a XP project is a sure sign that something is wrong with the process, and you would better fix what's wrong.

from "Extreme Programming Explained" by Ken Beck

Tenets of SOA and OOP principles

A service adheres to the common principles of object-oriented design, such as encapsulation and polymorphism, plus four more tenets:

·         Boundaries are explicit.

·         Services are autonomous.

·         Use contracts, not classes.

·         Compatibility is based on policy.

SOA in Practice

Applying SOA means extracting some practical design rules from the SOA tenets and measuring them in the context of a real system. Applying SOA principles to a service layer means having coarse-grained services that act as a remote façade facing the business logic.

As a result, you have the following practical rules:

·      Services in the service layer do not implement any business logic.

·      Services in the service layer script and consume the business logic whatever that logic might entail, including workflows, domain objects, and application services.

·      Application services—that is, services that implement pieces of the business—might or might not be SOAs themselves.

·      Data exchange happens through DTOs (via data contracts) and not by using classes in the domain model.

·      Services do not distribute and share objects, and service methods do not work on objects. Services are limited to getting and returning a collection of values formalized in a schema.

·      Services in the service layer should aim at a UI-oriented interface.

·      Application services should aim at a business-oriented interface.

·      Any services with an entity-based interface tend to expose plain CRUD operations. These services are referred to as CRUDy and, for what it matters, are not SOAs.

·      Services should be deployed and versioned independently of the system in which they are deployed and consumed.

·      To the extent that it is possible, do not modify service and data contracts. When you absolutely need to do that, apply versioning.

From “Microsoft .NET: Architecting Applications for the Enterprise” by  Dino Esposito and Andrea Saltarello

CRUDy and Chatty, extremely popular antipatterns of SOA

CRUDy interfaces are a fancy name; the real enemy is bad design.

The opposite of a chatty interface is a chunky interface. In a chunky interface, information for the service (as well as return values) is composed in a comprehensive document-like package. A badly designed CRUDy interface is also a chatty interface.

From “Microsoft .NET: Architecting Applications for the Enterprise” by Dino Esposito and Andrea Saltarello

First Law of Distributed Object Design: Don't distribute your objects!

Architect’s Dream, Developer’s Nightmare

Distributing an application by putting different components on different nodes sounds like a good idea, but the performance cost is steep.

A Better Way
Clustering involves putting several copies of the same application on different nodes. If you must distribute, this approach eliminates the latency problems.

From “Errant Architectures” authored by Martin Fowler

http://www.drdobbs.com/184414966

Manifesto to agile software development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

http://agilemanifesto.org/

About DTOs

The use of DTOs in conjunction with BOs (Business Entities or Domain Entities) is one of those topics that can trigger an endless, and sort of pointless, discussion within a team.

The theory suggests that DTOs are used in all cases to reduce coupling between layers and to lend the system greater formal neatness.

The practice, though, often reminds us that complexity is generally high enough that we should avoid any unnecessary additions.

As a practical rule, we suggest that when you deal with a model of a few hundred business objects, you probably don't want to double the number of classes just to be neater in your implementation. In this case, a DTO might likely be the same as a BO.

From Microsoft .NET: Architecting Applications for the Enterprise

Design Guidelines for Developing Class Libraries

http://msdn.microsoft.com/en-us/library/ms229042.aspx

Examples of Antipatterns

An anti-pattern is devious and insidious and adds more trouble than it removes. In the old days, we used to just call these bad ideas. The new name is much more diplomatic.

The Architecture-As-Requirements anti-pattern refers to situations where a prominent and influential member of the design team has a pet technology or product and absolutely wants to use it in the project—even when there is no clear evidence of its usefulness and applicability in the customer's context.

The Test-By-Release anti-pattern refers to releasing a software product without paying much attention to all those boring and time-consuming chores related to unit and integration testing. Are users the final recipients of the product? Great, let's give them the last word on whether the software works or not.

Know the business well to be in the business

Many years ago, when talking about choosing what to do when growing up, my father said to me “Find something you like to do, be good at it and figure out a way to make some money out of it.” With that advice I chosen software development as my career path and went with it for decades.

Come to think about it one needs to know the business (well) to be in the business. It is true to an architect, it  is true to a programmer. It is also true to a project manager. extend it to a larger Scale, it is also true to a company.