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