MCPD campaign is going on

"Exam 70-563: PRO: Designing and Developing Windows Applications Using Microsoft .NET Framework 3.5" is passed yerstaday!

My results were a bit worse then for Exam 70-536, espesially in area of data management planning. ...Hm, it seems I have to refresh my knowledge about app settings, user preferences and data; app config files, local/network folders, isolate storage, registry, roaming user profiles, local/remote databases...

Interesting thougts about UI

"Easy To Use" typically means "less time and money spent in training and an increase in user productivity".

UI goals are

keeping the userfrom making big mistakes and keeping the user from looking stupid

- from About Face: The Essentials of
User Interface Design (John Wiley & Sons, 1995) by Alan Cooper.

"Good enough for now" principle

It is not always easy to distiguish when requirements and/or design are incomplete because of some unknowns (this is what agile approach thight with) or this is just about somebody is too lasy to think and specify consistent details.
I think running project according to "just good enough for now" principle is a difficult balancing and finding what is really can't be unknown at the moment and what we just need to put some time to think about right now to save time later for rework.
...this balancing require wize and expirienced man. One more point why agile projects can't be run by novices.

Some links:
- "Just Barely Good Enough" Models and Documents: An Agile Best Practice

Duplication sometimes is allowed

Just a thougt that in some cases same or similar logic should be implemented in different places and this is "by design", recomended practice!
E.g. in case of validation it is recomended to implement as much validation as possibe near the input (e.g. on UI layer) but at the same time you have to duplication validation on back-end layer as well to follow defencive programming principle.
Similar principle of defend layers are used in security desing. In order to be secure system should be protected by several layers of defences (preferrably build on different technologies).

Why these thougts come to my mind? Just because sometimes developers are too concentrated on reuse for existing code and avoiding duplications in implementation. You have to realise that sometimes duplication is needed and can't be avoided.

Silverlight, ASP.NET AJAX, XBAP

What are differences and usage scenarious for Silverlight, ASP.NET AJAX, XBAP technologies?
It is clear that these are separated products. that have different internal architecture. Silverlight and XBAP provide similar developer expirience. It seems to me that XBAP is not so usefull approach nowadays and Silverlight will replace XBAP. Why should I use XBAP for intraner/corporate applications why not standalone WPF app deployed thru ClickOnce? For RIA Silverlight is defenitelly the winner for XBAP.

Some links I found usefull:
- When should I use WPF vs. Silverlight?
- XBAP and Silverlight


As for AJAX it looks to me as a complimentary technology for Silverlight. Ajax allow to use back-end services esely to build resposible client UI, while Silverlight is consentrated on client-side code. So this is more AJAX vs RIA comparison, where Silverlight is one of RIA technologies. But still you can do everything with Silverlight, so probably for the future Silverlight is a strategic technology choice for RIA.
- Ajax vs. Silverlight and .NET
- Silverlight and Apollo: AJAX Killers?
- AJAX vs RIA's and Flash vs. Silverlight

It interesting to know that alternatives for Silverlight are JavaFX and Flash/Flex.

My MCPD campaign is started

My compaing to archive MCPD status is started. The plan is to pass three exams:
- Exam 70-536: Microsoft .NET Framework - Application Development Foundation
- Exam 70-505: Microsoft .NET 3.5, Windows Forms App Dev
- Exam 70-563: PRO: Designing and Developing Windows Applications Using Microsoft .NET Framework 3.5
and gain "Microsoft Certified Professional Developer: Windows Developer 3.5" certification.

I found following resources are usefull in preparation:
- MS Learning Site
- MSDN Virtual Labs
- Rump-up

I have passed "Exam 70-536: Microsoft .NET Framework - Application Development Foundation" yerstaday! To my small surprise it was not so difficult as I expected. Probably I am overexpirienced for it?
I have registered for "Exam 70-563: PRO: Designing and Developing Windows Applications Using Microsoft .NET Framework 3.5" next week. I excpect it should be more diffucult, especialy taken in mind that I have no preparation/training materials for it.

How to violate OOP access modifiers?

.NET
Just found that reflection in .NET allows to violate class members access modifiers, e.g. you could easely get/set private class members. Isn't it a violation of basic OOP principles?
.NET reflection is subject to security checks. Full trust code can use reflections without restrictions otherwise you need ReflectionPermission with the ReflectionPermissionFlag.MemberAccess flag. See Security Considerations for Reflection for more details.

Another example is build-in serialization mechanizm in .NET. Again it has access to all private class members in order to serialize instance state.

Java
Quick investigation shows that Java has similar possibilities, but one additional level of protection. Private members are not accesible by default and even trusted code have to call FieldInfo.setAccessible(true) explicitly before accessing private field. Even if you call setAccessible(true) but running code has no enougth permissions (e.g. it is an applet) you will get access denied exeption (ReflectPermission).

Agile manifesto evolution

It was great to find this addition for Agile Manifesto.
Nice to know that software professionals around want emphasise quality and professionalism in our work.
Pure Agile Manifesto sounds a bit stripped to me without word about quality and high professional morale. It could couse confusion in students who have no professional expirience yet. From this point of view they see Agile Manifesto as a green light for cowboy undesciplined programming.

When Agile approach works

Basic Agile principles can be fully applied in highly professional teams only, when you have no problems with competencies and commitment. "People over processes" principle works only when people know what to do without much coaching. Only professional has skills and expirience to own the problem, commit into it, choose right tools/methodics from his portfollio, find optimal solution himself. Only professional has built-in internal "common sence" that is required to be agile and "self organized".

As soon as team is not skilled enouth you have no choice but setup a PROCESS to secure some level of success in the project and make success repeatable.
It seems to me that many cases when organization tries to go "agile" but do "traditional" instead is about people that are not skilled enougth. Often they do understand princeples and practices, but can't follow them just because people need more precise guidance.

"Disciplined agile" term is just about that. Professional developer is disciplined by nature, he/she don't need additional quidance to be "disciplined". For less skilled team you need to define "minimum precess requirements", "required practices" etc. but this is already not agile, you put process over people!

This is just as in any art you have to learn basics first in order to become a Master. Agility is for Masters.
The main goal of "Scrum Master" is to train "masters" that can be "self-organized". unfortunatelly it is rarely possible to do in a resonable timeframe with the "random" team. Team has to be formed already with this goal in mind: talanted people, not jouniors.

XP history

It was a surprise for me to see that Gradi Booch mentioned Extreeme Programming (XP) in his "Object Oriented Design and Analysis with Applications" book 2nd edition. He describes it as a very simplified version of RUP!

Sprint is not a mini-waterfall?

Agile iterations are often said as NOT a mini-waterfall? An analogy I head is a "run sprint is like put waterfall activities into blender". So all activities are going in parallel, not sequencial.

I agree with point that person who owns the task should not strictly and sequensially follow analys-design-code-test activities. It is up to him how to develop increment. BUT it is always good idea to plan up-from (i.e. analys) and think about how I am going to implement something (design activity) before actually doing something (coding activity). Finnaly you check that solution you implemented works (test activity). This is just how it works, othervise solution will be poor, errorprone, not maintainable, require rework etc.
For highly professional developers implementation path doesn't seem sequension because one have intuition and very good predicion for many issues. It seams that he/she is doing all activities in parallel, but I believe this is just illusion caused by professional master skills.

Common known fact that waterfall is the most optimal development model when we know exactly what we what to create. For single iteration/sprint we have this situation. Development team commited into "scope" for this particular iteration. Requirements inside this scope are frozen. So why not do mini-waterfall to archive commitment into most optimal manner?

Again thinking about Agile ws Waterfall I have a filling that "waterfall" model is commonly missinterpreted by software practioners. Waterfall like it was described by Dr. Winston W. Royce originally is not a sequentional process, it has feedback loops.

Lean vs Agile development

Lean development. How it is different from Agile?
Here is a quote from Slouching Towards Waterfall article (that I disagree in general):
"The agile philosophy is, basically, to place process in the service of people. Qualified and motivated people know what to do and will gladly do it provided they "own" the problem. They need processes that help them get things done, but that do not hinder them in acting autonomously. The lean philosophy, in contrast, is to make the process better so that people can follow it to success. In contrast to a traditional "heavyweight" or "high-ceremony" process, a lean process focuses on getting the job done and dispenses with steps that only add administrative overhead. The belief is that a well-designed lean process can lead "anyone" to success. All they need do is follow the steps the process defines for them, without deviation."

I think this thesis is also incorrect and Agile and Lean philosophy are inline.

"Staggered Iterative Waterfall" is it an anti-pattern?

I read couple of articles last week anout "Staggered Iterative Waterfall" anti-pattern: The Staggered-Iterative-Waterfall (Anti-)Pattern and Slouching Towards Waterfall. I read them several times was trying to understand, but I failed. My expirience tells me that "Staggered-Iterative-Waterfall" IS successfull pattern. I disagree with most point in those aticles.
It seems to me that we understand terms (like iteration, phase, Waterfall) very differently.

Analysis, Design, Construction or Testing are not phases, they generaly shouldn't be separated into different iterations. They are activities that exist in every iterations but you just put diferent pressure on different activities in different iterations thru-out project life-cycle.

Staggering (I think overlapping is better term here) is effective because analysis (product owner/manager role), construction (development) and verification (QA engeneer) are different roles in the project. It is nothing about "ability to communicate and collaborate". They just represent different views on the project and it is not good idea generally to combine these roles in a single person, they are conflicting roles. Product owner concentrate on maximizing product value, development team concentrate on building live product, QA concentrate on finding ways to check product in real-life environment. I personally think about dev and QA as two fighting forces that allow to build great product. Great thing can be burn only in a battle.

It sounds stupid to me that "product owner" should not think about user stories for iteration (n+1) while dev team working on iteration (n). As well as it is stupid to me that development team should not start iteration (n) until QA executing tests for e.g. stability, performance, scallabilty of delivery from iteration (n-1).

Looks like confusion come from different understanding for e.g. "testing" term. Developer level testing dev.team responsible for is defenitelly part of current iteration and this activity is mixed with all other construction activities dev.team do. But professional testing QA team does is a different thing, it is a parallel process that interferrer little with development testing.
The same confusion for "analisys". I am speaking not about "analisys" developer does but about busines level analisys what what features to deliver to market and how they should look like on general level.

Here is a post with critique of "Staggered Iterative Waterfall" anti-pattern I thound: Every Process is an Iterative Waterfall. I tend to agree with most tesises there.

Iteration duration

I offten think why in my practice I used to fail to apply short 2-4 weeks iterations usually suggested by agile mentors. I found that 8 week iteration is the optimal. It it not too long to be become unflexible and delivers increments often to facilitate feedback cycle. And at the same time it allows normal requirements analysis and development without hurry.

Here are some my ideas why it happened:
1. All my projects last 6 years were off-shore and near-shore projects where development team was located on different site from "product owner" (in terms of SCRUM). It means that there are difficulties with knowledge transfer from "product owner" to development team. We used to transfer this knowledge mostly thru functional specs. Well it was quite informal specs often, not formal documents. Delivery of such spec usually followed by Q&A session between development team and spec author.

2. Due to communication practices it was resonable to capture big enouth chunk of requirements at once and transfer it to team. It would just be too time consuming for everybody to do requirements transfer every 2-4 weeks.

3. Functionality/user stories planned for single iteration usually were too big to be done in 2-4 weeks. It were possible to devide them of cause into sub-functions (and we did it as internal checkpoints inside iteration) but there was no sense to deliver those intermediate milestones to "product owner".

4. Often "product owner" is not ready to consume deliveries every 2-4 weeks. THe reason could be that "product owner" is just busy with something else. Depends of the feature also. Some features require sagnificant preparations to check, test, verify.

5. Interesting fact that increases my confusion about 2-4 weeks recomendation even more is that we used "staggered iterative development". Requirements analysis, construction and verification functions were distributed between different subteams that worked in parallel. While "product owner" works on specs for (n+1) iteration, development team worked on iteration (n) constraction. Testing team slitly overlap with development team. Testers works on verification of (n-1) at the begining of (n) constration and then continue on test cases creation for (n). May be better to think about it as a special period between iterations (about 2 weeks) while developers and testers stabilyse (n-1) and start (n) construction. There could be also external "functional testing" tean that works with (n-x) while (n) construction to help "product owner" to build vision, to get feedback from "end users", etc.

My current opinion that short (2-4 weeks) iterations sutable mostly for small projects and on maintenance projects where changes are small and team is small and colocated. It is important that "product owner" is near and ready to consume deliveries often enough.
I learned also that short iterations doesn whorl if there are no true "product owner" or he doing his job by "left hand" (working on other more important projects semultenously). In this case "product owner" just cannot give feedback so quickly.

But all abouve doesn't mean that development team should not use internal "micro-iterations" (or let's call it checkpoints). This is a very usefull technique together with timeboxing to concentrate to "good enouth for now" results.

Technical debt

Technical debt is a great analogy I love.
Making a quick dirty change in the code to save time before delivery is a "technical debt". Like "financial debt" you have to pay it later probably with some interest

Overlapping stages, timeboxing and sign-off

To continue my yestaday's thoughts about collisions between agile practices and real busines...
How can we apply overlapping approach while having sign-off project plan? I think overlapping can be used for construction iterations (design-implement-verify circles). That time team works on implementation for vision agreed on "requirements" stage and fixed in ProjectPlan.
So sign-off is applied for first kick-off/initiation phase. Then proceses of refining requirements/changing vision and construction of agreed vision are going cemultenously. As well as release/deployment and support/maintenance activities are spawned after construction is finished. This is also an example when we can't use overlapping: release can't be build until construction is finished.

Requirements/vision review activities going on while consuction is active and provide corrections/steering for following construction iterations. Agile here means that construction use short iterations to provide usable product as an input and adapt to changed vision/requirements quickly (in next iteration already).

SOA evolution

SaaS and on-premise are deployment options for software.
Three types of services (in MS terminology): finished, attached, building block.
Software-plus-Service is a MS strategy for for combination of hosted and on-premise solutions. This is a step toward cloud compiting initiative.

Collisions between Agile and real life

1. Some collisions between Agile ideas and real life business that come to my mind:
   The importance of oficial "sign-off" before moving to the next step is commonly recognized. Otherwise, you can't control the process: there is a great risk of complains that team is doing wrong job. You will end up arguing about things you took for granted when it's too late to change them without wasting a lot of time and money. But this tesis conflicts with agile practices of overlapped stages/phases and iterations when you move to next development stage before previous stage fully closed. Without overlapping stages we go to "waterfall" approach!
   
   May be the solution for the problem is that upfront sign-off/approval required only for key documents required before actual development can be started: business plan, vision statement, overall project plan.
   
   Additional thought here that overlapping stages approach also conflicts with requirement (from "agile" iterative incremental development mothodology) to continiosly have a releasable product with good quality. It means that we have to stabilize the codebase each time after change is introduced before going to next change. This is why "entry and exit criteria" offen used for milestones/legs/stages.
   Oops, seems it conflicts timeboxing principle? I think timeboxing in this case means that we have to revise "exit criteria", understand what was left-out and make a decition according our current "best understanding" should it be done ASAP in the next timebox or postponed. So in this case "exit criteria"just allows us to have good understanding of differences between original expectation and realization.
2. Here is a story I head from my friend just yestaday how timeboxing principle was violated. My friend is working for sw dev company who adopted SCRUM practices thru whole enterprise. But management forced to extend last sprint when they realised development can't compete all features that where estimated for this spring. This story is the key to question why "waterfall" is still so popular. Business what to have good prediction and plans!

Microsoft Solution Framework

Microsoft Solution Framework (MSF) had many very good points. E.g.

• Project Manager role is devided into Product and Program Manager (like Product Owner and Scrum Master!).
• Program Manager is facilitator that plays administratice role, not a dictator in traditional ProjectManager's style. All decisions are made by team collectivelly.
• Leaving documents to avoid analysis paralysis (no need to fully complete document before moving to next phase)
• Versioned releases. This is a rule how to drive incremental development: devide solution into independent pieces. (Isn't it similar to SCRUM's backlog approach?!)

BTW, you can learn what happens with MSF nowadays from "Engineering Windows 7" blog. It looks like next evolution of MSF...

Software development terminology chaos

Standard Development Life Cycle (SDLC), Waterfall, Spiral, Rapid Application Development (RAD), Rational Unified Process (RUP), Microsoft Solution Framework (MSF)...
Prototyping, Object-oriented (O-O), Agile
SCRUM, XP

So many terms, but what is the core knowledge? How to distinguish frameworks, methodologies, approaches? ...

I am confused at the moment but here are some random thoughts:

SDLC defince basic activities in project. "Waterfall" (commonly misunderstood) adds additional decision points and feedback loops. Spiral methodology allow continious endless product evolution as a recognition that end result is always unknown. RAD emphasis flexibility and observe-adapt circles thru short iterations and prototyping. Iterative and incremental life circles are core ideas for all modern software methodologies.

Looks like RUP and MSF are frameworks that follow RAD methodology. But different approaches could be applied while using these frameworks. Like RUP can be executed both as traditional approach and as agile approach.

Why "traditional" methodology SDLC is so popular? Just because organizations need to understand when will they get specific functionality and how to budget and manage accordingly.

SCRUM is just set of clearly formulated rules to apply that are formulated so that should be clear even for for dummies, but generally speaking this is an instance of iterative, incremental RAD methodology plus concrete approach with set of defined practices.

What I don't like in scrum that it prescribe too many practices. Development methodology should inspire, not prescribe. It should be like a toolbox of best practices to choose from. Software development projects are not repeatable. Every time you have to build a new process for new project.

May be one of the key innovation ideas behind Agile approaches is a backlog (in SCRUM terms). This is an approach how to manage projects according to prioritized list of missed things, not according to predefined plan.

Observation-adaptation circles, collective decision making (without Project Manager) are well known generic management practices.