Simple WPF reference solution

Did you ever wonder what might be a nice and basic skeleton of a simple WPF application?

Did you ever have that desire to find a basic WPF project, that you could use as a reference if you ever forgot something?

Did you ever have that feeling, when working for several months, or maybe years, with a technology, then switching to another one for some time (completely different), and returning to the previous one, that you are technologically lost even in the most simple things?

I can say for sure that I did, and because of this, I propose to you a solution that I've built for several years, for myself, based on my experience on small but live projects.

The history started several years ago, when I needed to work on WPF projects, then switching to something else, then coming back and not remembering how to do things, and AGAIN searching the WEB, the stackoverflow, finding solutions and wasting valuable time.

One day, I've said to myself: that must stop! I need to gather all information I need, create a simple reference project for myself, and when I don't know something, I just open it, and look how I've done something before.

Now, I think, has come the time to share this little project with others.

It does not contain everything though, but most basic ideas, and I will be grateful for any comment/suggestion that you'll might have.

The solution was re-created for Visual Studio 2013, and contains the following projects:

WPF_MVVM contains the main window.

XMightCommon contains all generic non UI code, that can be reused in many projects.

XMightUICommon contains all generic UI code, that can be reused in many projects.

Topics covered in the solution:

1. Creation of a WPF window
2. ViewModel
3. Binding
4. RelayCommand
5. UserControl with INotifyPropertyChanged
6. Dependency Properties
7. Resource dictionaries
8. Animation
9. Resources
10. Control Templates
11. Converters
12. Custom StartupUri
13. Busy/Loading animation while executing action.
14. Logging to UI console
15. log4net
16. RollingFileAppender

I wish this project to be useful to you and if you find it useful, I will be grateful for any acknowledgement!

Source

Software development teams organization laws

Today, I would like to dedicate my post to the management side of the software development process, and especially to the team organization laws.

I was inspired by a post on an IT specialized website which I follow. I was impressed about the usefullness of these laws and the concise flow of the presentation.

At the end of the artile, the source was mentioned, a book in progress by Alan Kelly, entitled: "Xanpan book 2: The means of production".

I find the way these laws are presented very nice and tidy, so I thought that sharing this, or at least backing this up as a later "Must read" for myself is a very good idea.

Instead of copying what is mentioned in the article, or in the book (which you can read online for free, at least at the time of this post creation), I thought it would be nice to have it in a format like this:

1. Law name
2. Statement
3. Source (wikipedia)
4. Optional short explanation/example

So, you can find below a very concise presentation of these laws.

Also, if you want more info on the topic, feel free to access links below the post.

Basic Laws of constructing development teams:

1. Brooks'law:claim about software project management according to which "adding manpower to a late software project makes it later".

Source

2. Conway's law: organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

Source

3. Dunbar's number: is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships (150 max).

Proponents assert that numbers larger than this generally require more restrictive rules, laws, and enforced norms to maintain a stable, cohesive group.

Source

4. Miller's law, 7 +- 2: the number of objects an average human can hold in working memory is 7 ± 2.

Practical example: It is recommended that a Scrum team match the number 7+-2. Teams with more than 9 people create too many coordination problems.

This rule does not include Scrum master and Product Owner, except if they are not included in the sprint to reduce delay.

Source

5. Parkinson's law: the work expands so as to fill the time available for its completion.

Practical example: a sufficiently large bureaucracy will generate enough internal work to keep itself 'busy' and so justify its continued existence without commensurate output.

Source

6. Hofstadter's law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Practical example: difficulty of accurately estimating the time it will take to complete tasks of substantial complexity. You might estimate more than you think, and even this might not be enough

Source

7. Kelly's first law of Project Complexity: Project scope will always increase in proportion to resources

Concise example: Putting more people to work will have an inverse effect on the results and more probably not fulfill expectations.

Source

8. Kelly's second law of Project Complexity: Inside every large project there is a small one struggling to get out

Explanation: If you have a project with lots of resources, the original project will get lost inside of it.

Source

9. Gall's law: Complex working system is always created from simple working systems. A complex system built from scratch will never work.

Explanation: Start the project small, and grow up gradually.

Source

Interesting fact: If you by mistake (as I did) search instead of Gall's law, Hall's law, you will, very likely end up reading this Wikipedia article.

Strange as it might seem, but one might find a tight connection between Gall's law and what this inventor John Hall did, not counting the coincidence in First Name!

Sources:

Xanpan2 by Alan Kelly

The article which inspired me, in Russian

Principles of Software Development by Alan Kelly

Hall's law prequel to Moore's law