Learn Software Development » Architecture

Problem in Scrum: Looking at technical debt, which will cause more problems as you move ahead ..

ashish — Tue, 04 Oct 2011 14:24:11 +0000

What is technical debt ? Well, I will not try and give a definition for technical debt. Instead, consider that you have 2 approaches to build some great new features. You can do something in a quick way without trying to build a great design, or you can build it the proper way through the required design. Now, if you need to get features done quickly, then trying to build in the proper design and architecture can stretch the possibility of getting the features done in time for the need (say, if the team is under pressure due to market requirements, or due to external stakeholder pressure). In such cases, it is a business need to build the feature done quickly enough, but one of the problems of taking such an approach is that you need to build a structure in order to build more and more features, and as you neglect the design work, building features becomes even more difficult. To put it in another way, in order to save some time in the beginning, you spend more time later. This is what is called technical debt.
In the case of the Scrum process, what I have seen in practice in many teams is the concept that because of the pressures, because of the way that the team seems to work from a Sprint to Sprint, the tendency to think about architectural change can slip by. The whole team is driven through a process whereby the Product Owner defines a set of features, prioritizes them, these are broken down into discrete tasks and estimated and then implemented by the team. There can be a lot of pressure to ensure that the teams are delivering a set of features on a regular basis; further, people are occupied on ensuring that all the features are delivered on time. It can get pretty difficult to insist that architectural tasks are delivered, since there can be a lot of resistance to putting these tasks into the Product Backlog. It would typically need somebody of the stature of an engineering manager to have those discussions with the Product Owner, to explain the need to put in the engineering time for putting in design for building for more features. It can be difficult at times, and in our case, it took us a few months and one round of feature failure to explain the engineering design process in detail to the Product Owner, and now we are in such a condition that the Product Owner totally understands when we push for some architecture work. However, it can take time for the Product Owner to be comfortable with these details.

Problem in Scrum: Inability to prioritize the architectural and design tasks – Part 2

ashish — Mon, 03 Oct 2011 14:21:32 +0000

In the previous post (Not putting design priority), I had talked about how a Scrum team can face challenges in terms of prioritizing the architecture and design tasks. In this post, I will continue my previous discussions and talk about how teams do actually place a lot of emphasis on the design part, and how this has to be driven by somebody.
I was recently talking to an engineering manager who was part of a team that was working on a product (or rather, the people in the Scrum team reported into the engineering manager). When I asked the same question, about how the team managed to ensure that they did not get into a situation where the design work was not planned for, the engineering manager was quite emphatic on this subject, that the team ensured that all the required architecture and design work was planned and the team ensured that in discussions with the Product Owner, these were incorporated into the Product Backlog and actually implemented as part of ongoing Sprints.
Sometimes, such an approach can be problematic. Part of the philosophy about Agile that I have heard often enough is the need to avoid doing unnecessary work. Sometimes, it does happen that the architecture work that is planned for the cycle is actually an overkill, and when the work is done, you realize later that the feature for which this architecture was planned and executed was not required. This can be painful, and when such a scenario occurs, there can be disagreements with the Product Owner. We had a case once before where we were supposed to be building a great new feature that dealt with the interaction between the client server application and an internet based client chat and forum system. This system was not in place earlier, and hence the entire application layer that dealt with integration of the API’s of the web application was integrated, so that in later cycles, the user interface would be built and tested. However, in a change of plan (caused due to new features integrated by an opponent), we dropped the internet based system integration and built in a new feature that was a core feature.
As a result, all the architecture work that we built in had to be dropped, and all the time that was spent in this work was also wasted. Also, there was no certainty that the work that was done would be used sometime in the future, since the feature may or may not be needed in the future. On the other hand, if we needed to put in the feature, it was necessary to make the architecture change in earlier Sprints, so that the software had the base built for the user interface feature. This was a ‘necessary evil’, and in the end, if the feature was needed to be done, the necessary architecture was required to be in place in advance. For most features that are big and require such architecture work, such planning is required.

Problem in Scrum: Inability to prioritize the architectural and design tasks – Part 1

ashish — Fri, 30 Sep 2011 19:18:34 +0000

Over a period of time, some of the discussions that I have had with fellow managers, and more specifically with managers who play the role of Scrum Masters come to a conclusion revealing a weakness in Scrum implementation. Projects where there is initial time spent on planning the architecture and design for the end project tend to have a good design that is scalable, where the individual components (and the flow between them) and the overall design has been well thought out. Sometimes, the amount of time spent in design and architecture seems like an overkill, but in most cases, the amount of time spent is the amount of time required for such activities.
However, one of the biggest problems that has been seen in the implementations of Scrum that I have observed relates to the planning for design tasks. In a typical waterfall methodology, the schedule is split into properly defined and demarcated times for the implementation of all the design work, and the product seems all the better for that. However, when you get into the game of having a Sprint where all the User Stories for that Sprint should be implemented by the end of the Sprint, where the Product Manager defines all the User Stories (and is lead to believe that the Product Owner controls a large chunk of what the engineering team is actually doing). As a result, when you have design tasks that could take multiple Sprints to complete, many times the engineering team cribs about the limited amount of time that they get for doing such a task and believe that the design work is not really complete and can cause problems as the project schedule moves ahead.
Consider the case where the User Stories are defined and added to the Product Backlog. Ideally, these should include the tasks related to design and architecture so that they can be properly prioritized and planned for completion in the required Sprint cycles. But, when the overall requirements are not constant, or are broken down into small parts, it does get more difficult to come up with a proper and structured design document which covers the need. In addition, for many teams, it can be hard to convince the Product Owner about the need to do large architectural tasks, especially when they do not relate to features, or may be needed for features that may or may not be required.
Overcoming such challenges requires a lot of planning, and some work outside the regular Sprint planning cycle, but teams need to do this in order to ensure that they have a good design.

Introduction to Data Binding

ashish — Sat, 12 Sep 2009 06:52:18 +0000

Data binding is the process that establishes a connection between the application UI and business logic. If the binding has the correct settings and the data provides the proper notifications, then, when the data changes its value, the elements that are bound to the data reflect changes automatically. Data binding can also mean that if an outer representation of the data in an element changes, then the underlying data can be automatically updated to reflect the change. A typical use of data binding is to place server or local configuration data into forms or other UI controls.

Basic Data Binding Concepts :
Data binding is based on a component architecture that consists of four major pieces : the data source object (DSO), data consumers, the binding agent, and the table repetition agent. Data source objects provide the data to a page, data-consuming HTML elements display the data, and the agents ensure that both the provider and the consumer are synchronized.

Direction of the Data Flow :
The data flow of a binding can go from the binding target to the binding source and/or from the binding source to the binding target.
- One Way binding causes changes to the source property to automatically update the target property, but changes to the target property are not propagated back to the source property. This type of binding is appropriate if the control being bound is implicitly read-only.
- Two Way binding causes changes to either the source property or the target property to automatically update the other. This type of binding is appropriate for editable forms or other fully-interactive UI scenarios. Most properties default to One Way binding, but some dependency properties default to Two Way binding.
- OneWayToSource is the reverse of OneWay binding; it updates the source property when the target property changes. One example scenario is if you only need to re-evaluate the source value from the UI.

Data Source Objects
To bind data to the elements of an HTML page in Windows Internet Explorer, a DSO must be present on that page. DSOs implement an open specification that leaves it up to the DSO developer to determine the following:
- How the data is transmitted to the page. A DSO can use any transport protocol it chooses. This might be a standard Internet protocol, such as HTTP or simple file I/O. A DSO also determines whether the transmission occurs synchronously or asynchronously. Asynchronous transmission is preferred, because it provides the most immediate interactivity to the user.
- How the data set is specified. A DSO might require an Open Database Connectivity (ODBC) connection string and an Structured Query Language (SQL) statement, or it might accept a simple URL.
- How the data is manipulated through scripts. Since the DSO maintains the data on the client, it also manages how the data is sorted and filtered.
- Whether updates are allowed.

Data Consumers
Data consumers are elements on the HTML page that are capable of rendering the data supplied by a DSO. Elements include many of those intrinsic to HTML, as well as custom objects implemented as Java applets or Microsoft ActiveX Controls.
A DSO typically exposes this functionality through an object model that is accessible to scripts.

Binding Agents
The binding and repetition agents are implemented by MSHTML.dll, the HTML viewer for Internet Explorer, and they work completely behind the scenes. When a page is first loaded, the binding agent finds the DSOs and the data consumers among those elements on the page. Once the binding agent recognizes all DSOs and data consumers, it maintains the synchronization of the data that flows between them.

Introduction to Relational Databases

ashish — Wed, 09 Sep 2009 19:23:55 +0000

Relational databases are probably the most common type of database used for general-purpose tasks. In a relational database, information is grouped according to its type, generally in tables (see below). For example, in a database designed to hold fleet information you may include a table of employees and a table of vehicles.
- In addition to separating information according to its data structure, a relational database allows relationships to be created. A relationship defines a possible link between data types; the actual linkage of data is dependent upon the information held.
- Relational databases use the concept of normalization. Normalization is a design technique that minimizes the duplication of information. It also reduces the risk of errors. By using relationships, the duplication required can be lessened or eliminated completely.
A Relational model is the basis for any relational database management system (RDBMS). A relational model has mainly three components:
- A collection of objects or relations.
- Operators that act on the objects or relations.
- Data integrity methods.

Elements of a Relational Database Schema :
There are several key elements to a relational database. Each of these forms a part of the database’s schema. The schema is the logical data model that determines the information that may be stored in the database and how it is to be arranged. To design a database we need three things:
- Table : A table is one of the most important ingredient to design the database. It is also known as a relation, and is a two dimensional structure used to hold related information. A database consists of one or more tables.
- Rows : A table contains rows. Rows are collection of instance of one thing.
- Columns : A table contains the columns. Columns contains all the information of a single type. Each column in a table is a category of information referred to as a field.
- Indexes : One of the greatest benefits of holding information in a database is the ability to quickly retrieve it. When querying a database, it is possible to apply criteria to ask for a specific set of rows.
- Keys : A primary key is a single column, or group of several columns (compound key), that can be used to uniquely identify rows in a table. Each table in a database may have a single primary key. Once defined, no two rows in the table may contain matching data in the primary key columns. Foreign keys are used when defining relationships between tables. A foreign key is a single column, or group of columns, in a table that reference the primary key in another table. This creates a link between the two tables.
- Constraints : Constraints are rules that are applied to the information in a database. These are usually used to enforce business rules upon the tabular data.
- Views : Views provide the useful concept of virtual tables. A view gathers specific information from one or more sources and presents it in the format of a single table. The information may be filtered within the view to remove unnecessary information.
- Stored Procedures : A stored procedure is a predefined set of statements that can be executed when required. Stored procedures provide the main means of creating programs within SQL Server databases.

Domain and Integrity Constraints :
* Domain Constraints
o limit the range of domain values of an attribute
o specify uniqueness and `nullness’ of an attribute
o specify a default value for an attribute when no value is provided.
* Entity Integrity
o every tuple is uniquely identified by a unique non-null attribute, the primary key.
* Referential Integrity
o rows in different tables are correctly related by valid key values (`foreign’ keys refer to primary keys).