Agile MindStorm - Ideas, Actions, Results !!!

Most developers are very skeptical about design patterns. It is very common to hear that patterns are academic nonsense and useless. But anyway it is not true, and patterns can be very pragmatic and highly useful in everyday work.

Main advantages

• Patterns are good abstractions that provide building blocks for system design.

• Patterns take away focus from code reuse and move the focus to knowledge reuse.

• Patterns aren't invented, but rather harvested or distilled. It's about proven solutions.

• Patterns are described in three pieces: the context, the problem, and the solution.

• Patterns are very important part of the language within a development team.

Instead of having to describe each and every design idea in minute detail, it's often enough to say a pattern name and everybody in the team can evaluate whether or not it's a good idea for that particular problem.

• Ability to utilize patterns is a long-lasting skill. Patterns are language-/product-/platform-agnostic.

Also patterns are very much in line with the principles (treat like a guide, not like “the only truth”) of good object-oriented design.

Single Responsibility Principle (SRP)

An item such as a class should just have one responsibility and solve that responsibility well. If a class is responsible both for presentation and data access, that's a good example of a class breaking SRP.

Open-Closed Principle (OCP)

A class should be closed for modification, but open for extension. When you change a class, there is always a risk that you will break something. But if instead of modifying the class you extend it with a sub-class, that's a less risky change.

Liskov Substitution Principle (LSP)

Assume that you have an inheritance hierarchy with Person and Student. Wherever you can use Person, you should also be able to use a Student, because Student is a subclass of Person. At first this might sound like that's always the case automatically, but when you start thinking about reflection (reflection is a technique for being able to programmatically inspect the type of an instance and read and set its properties and fields and call its methods, without knowing about the type beforehand), for example, it's not so obvious anymore. A method that uses reflection for dealing with Person might not expect Student.

Sometimes it is very important to know in JavaScript which button was clicked. Such information might be useful when we want to change execution sequence in other methods.

Since global event method works a bit differently in Firefox (doesn’t have element’s id), I had to make workaround which would be acceptable both for Internet Explorer and Firefox. Probably it is not the best one and any other ideas and solutions would be greatly appreciated. J

I implemented this workaround using hidden text field. Here comes the code:

Page.aspx file

<script type="text/javascript">

function btnGenerateClicked()

{

document.getElementById('btnGenerateClickedIndicator').value = 1;

}

</script>

…

function OtherFunction(){

if (document.getElementById('btnGenerateClickedIndicator').value == 1)

{//one workflow

}else{//another workflow

}

}

<asp:Button ID="btnGenerateXLS" runat="server" Text="Generate Excel File" OnClick="btnGenerateXLS_Click" />

<input id="btnGenerateClickedIndicator" type="hidden" value = "0" />

Page.aspx.cs file

protected void Page_Load(object sender, EventArgs e)

{

this.btnGenerateXLS.Attributes.Add("onclick", "javascript:btnGenerateClicked();");

}

In my case that another function stands for a displaying overlaying div protecting from user clicking on other buttons during postback. But during excel generation I don’t need that because I change the response on btnGenerateXLS_Click.

What makes managing of software product development from software project development? What are the key issues we have to concentrate on?

Obvious difference which comes to our mind is that development of software product may consist of one or more projects. And vice versa is not possible.

Another way is to think in terms of hierarchy which is quite similar to the previous idea. Let’s call a product (or an application) XYZ. XYZ has a variety of projects that must be completed to offer XYZ to the public. Besides the obvious coding and testing of an application (also there might be different projects targeting different markets like the USA and the EU), there are marketing projects, perhaps packaging and/or distribution considerations, and at least one "support" project to model. It might contain even more.

But still it doesn’t help us to indicate key differences. Here come definitions.

‘Software Product management' - as it refers to in current industry is the process of conceptualizing a product and handing it off to development.

'Software project management' - is the process of developing the software product and taking it to completion in the given budget and time. The budget and time are put forth during conceptualization/product management phase.

Scope

The product part of software product development implies the inclusion of market planning and launch as part of the scope of activities. Product Managers handle a very different scope than project managers. Of course in small companies, one person may wear both hats.

Product managers deliver products to business strategy and may have P&L responsibility for the product throughout its lifecycle - from concept to end of life. This lifecycle may include software projects.

Project managers deliver specific scope to schedule, within budget.

Typically a software project produces a set of code in some form designed to solve a specific set of business requirements, either internal or for the market. Software projects ideally follow a Software Development Life Cycle or SDLC and involve steps including requirements development, architectural design, coding, and testing. Once testing is complete, software destined for a product is integrated and launched to the market. Software for information technology is deployed. These final activities may or may not be included under the scope of the specific software project. The whole of a software project is part of the overall management of the product.

Customer segments

So there are some internal software projects with very complex sets of customers that are as demanding as simple external software products developed for a few types of customers -- but these are exceptions.

Generally non-product software projects are done to satisfy a set of customers and stakeholders known at the beginning of the project.

A software product project also starts with targeted customer segments, but has the hope that the customer base will expand beyond that in the future. So getting the architecture right is even more important. Competitive issues also require careful consideration.

Product management is NOT the management of a number of sub-projects. That's program management.

Design

Product development needs to be designed to be "generic" and flexible to cater to unknown scenarios. For a project development, the design need not necessarily be very generic. Assumptions can be made, and some hard-coding may be allowed. However, it is always a good practice to follow the industry standard patterns, and design methodologies.

Testing

Product development testing is more complex, since it needs to consider all possible scenarios - in terms of functionality, volume, and performance. For a project, typically the user base, business process, scenarios, and volume/performance are known, and specific tests can be done to accommodate the requirements.

I've recently found a very interesting web site which allows you to compare salary against others in the same field :)
Check this out - IT salary! It might be that you are overpaid. :)

It's a common situation when we have alternate number of parameters in stored procedure.

Trivial example:
We need to perform some kind of calculations for a specific marketing campaigns. (User selects campaigns setting checkboxes from gridview)

Solution:
SQL Server's XML type comes to the rescue. We need to create similar string containing valid xml and pass it like a parameter to a desired stored procedure.
' <root>
<campaignid id="153">
<campaignid id="1">
</root>'


And we can use this string in the stored procedure like this:

declare @xml xml;
set @xml =
' <root>
<campaignid id="1234">
<campaignid id="12345">
</campaignid>'


SELECT *
FROM [TableName]
WHERE [TableName].[ID] IN
(
select
campaigns.id.value('@id', 'int')
from
@xml.nodes('/root/campaignID') as campaigns(id)
)

Very simple and nice solution

"A problem shared is a problem halved". When it comes to working your way through the challenges that you face every day, it's a great help to be able to draw on a network of supportive individuals that you can work with to find a solution.

I've recently found a very handy procedure for generating insert statements.
Take a look - Generate sql inserts.

A very nice and fast way to concatenate strings in SQL Server 2005

SELECT outerTable.[ID_Col] ID
, (
SELECT innerTable.[Text_Col] + '|'
FROM [YourTable] innerTable
WHERE innerTable.[ID_Col] = outerTable.[ID_Col] FOR XML PATH('')
) [ConcatenatedString]
FROM [YourTable] outerTable
GROUP BY outerTable.[ID_Col]

To use this all you need to do is to replace dummy names :)

Of course you might create aggregate function using .NET - Invoking CLR User-Defined Aggregate Functions
But in SQL Server 2005 aggregate function has limitation (8000 bytes) for returning value :(

Microsoft team removed this limitation in SQL Server 2008. But the serialization format will have to be UserDefined, because the limit for Native is still 8000.
So the attribute looks like this:
[SqlUserDefinedAggregate(Format.UserDefined, MaxByteSize=-1,IsNullIfEmpty=true)]

It is a very common situation that requirements are changing quite often half way through the project. Such situation puts a lot of pressure on budget and delivery dates. As a result project team is also being put under pressure. Before trying to think of how to deal with this situation, let’s think of what are the reasons of changing the requirements.

Quite obvious answer comes to a head first - project scope is fixed for a period of time, yet customer’s business is constantly changing. And the longer our project is, the more likely it is that customer will change the requirements!

Set it in concrete
Define a complete set of deliverables that you need to produce for your customer in depth. This will help to define the scope of the project in depth.

Plan it out
Not just write all the activities which need to be implemented. Instead, all activities should be grouped in project plan under the relevant deliverables. This will help you to track which activities are related to specific deliverables.

Monitor quality
It is important to complete all the deliverables in the project plan. And it is very important that these deliverables meet your customer expectations.

Manage changes
Every time customer changes their requirements, make sure that their change request is documented. After this action impact of the change request on project’s deliverables must be reviewed. And depending on the impact make a decision: sign off the change, hound customer for more money, time, people or anything you need to implement the change.

Report everything
Report on any changes that have happened and their effect on the project. This will ensure that if you pass your project deadline, you can show that it was the change requests that caused it. Customer will be more understanding (as they probably requested the changes in the first place) and your team won't go into "crises mode" as most teams do when they are officially ‘late'.