TeamPlain Web Access for Team System now FREE!!!!

TeamPlain Web Access for Team System is now a free download.

Microsoft's acquisition of the company has resulted in making TeamPlain Web Access for Team System a free download.

Get It Here.

WAE UML Stereotypes, Stencils, Templates, and ASP.NET Patterns for Visio

Over the past couple years I have been using Sparx EA for my UML documentation. In the past I have used Visio extensively.

I have noticed quite a few people searching for the Web Application Extension (WAE) for UML lately. I have uploaded the templates that I used in the past.

They include the WAE in two versions and also include ASP.NET patterns I used as a reference.

The Web Application Extension is covered in this book. The author, Jim Conallen, also has a paper posted here on the WAE.

There are also some other templates included the download. It includes the Enterprise Integration Patterns stencil and the UML 2.0 Icons and Stereotypes stencil. The UML 2.0 stencils came from here, so you may want to check for updates.

The ASP.NET patterns do not allow for the editing of the actual objects, but they do make for a nice reference.

Take them as they are….

Get them here.

New 2007 Release of the Guidance Automation Extensions (GAX) and Guidance Automation Toolkit (GAT)

The Guidance Automation Extensions (GAX) enable you to run Guidance Packages, such as the Guidance Automation Toolkit or those included in Software Factories. You can use the Guidance Automation Toolkit (GAT) to author or customize Guidance Packages.

We have used them to wrap frameworks provided during our product line engineering processes.

You can get information on the Guidance Automation Extensions and Guidance Automation Toolkit here and here.

I would read the 2 links below before installing:
Guidance Automation Extensions Improvement List
Tom Hollander's Announcement

You can download the
Guidance Automation Extensions here
And the
Guidance Automation Toolkit here

Install the Guidance Automation Extensions first.

SMART CLIENT in .NET 3.0: ACROPOLIS APPLICATION FRAMEWORK

UPDATED INFO (6-05-2007) on Acropolis here.

In this posted I asked if anyone heard of anything in the works at Microsoft to deliver a Smart Client Software Factory using WPF, WCF, and WF?

It appears it is coming, but when is still a question.

More information is coming at the end of March at the Visual Studio Connections March 25-28 in Orlando Florida, MAYBE????

In this brochure on Page 9 you'll find this ad:

MICROSOFT DAY • MONDAY, MARCH 26 • MICROSOFT DAY
SMART CLIENT: INTRODUCING THE ACROPOLIS APPLICATION FRAMEWORK
MICROSOFT
“Acropolis“ is the code name for a framework that supports the rapid development, deployment, and management of composite client applications. “Acropolis“ includes design-time tools, run-time components, and a management infrastructure. “Acropolis“ produces flexible and powerful client applications that leverage .NET Framework 3.0 technologies, such as Windows Presentation Foundation (WPF) and Windows Workflow Foundation (WF).

But I could not find it on any schedule. They may have called it by a different name?

Here are a few links I found and was given by some friends, but most of them do not provide much information:
'Acropolis': Another Smart-Client Tool for Microsoft's Arsenal
"Friends of Client Development Newsletter"
Discussion Thread: Where is Acropolis? – Revolutionizing Smart Client Development
Acropolis

Like I said in my other Blog posting, my main reason for asking is it is time for my company to put together a Smart Client Framework using .NET 3.0 technologies, and I don't want to reinvent the wheel. We moved too fast with the CAB and build an entire framework around it a few months before the Smart Client Software Factory came out. We would have used that as our foundation, but we had more functionality build into our framework than what was in the Smart Client Software Factory, so we never spent the time to move over to the Smart Client Software Factory.

It would be nice to get more information from the source on this, but it looks like we will be waiting a while.

Smart Client Software Factory using WCF, WPF, and WF?

This is simply a question I am posting to the community.

Has anyone heard of anything in the works at Microsoft to deliver a Smart Client Software Factory using WPF, WCF, and WF? I know they updated the Web Service Software Factory to use WCF, but I am wondering if they intent to do that with the Smart Client Software Factory as well?

My main reason for asking is it is time for my company to put together a Smart Client Framework using .NET 3.0 technologies, and I don't want to reinvent the wheel.

We moved too fast with the CAB and build an entire framework around it a few months before the Smart Client Software Factory came out. We would have used that as our foundation, but we had more functionality build into our framework than what was in the Smart Client Software Factory, so we never spent the time to move over.

Please post feedback as a comment.

Thanks in advance…

Customer Buttlodgentitus- I want what I want when I say I want it.

I love delivering software projects on time. It is one of the highest goals we set as architects. Being able to give an accurate estimate comes from metrics measured from previous projects. When we are allowed to give estimates, we are usually always able to hit our deadlines.

There are some projects that we are on that we know we are not going to ever hit a deadline on, and we are never going to be asked for an estimate in order to try to hit a deadline. The customer simply tells us what they want and when they want it. They have no idea if the request is complex or simple in nature. They have no idea if we need to get more resources for the project. They have no idea about anything, except that they promised they would have it to someone else by a certain date. Quite often you find this type of behavior coming out of the sales force.

I wonder if these people go into Burger King, order a # 5, and finish the order by saying, and I would like that done in 60 seconds. Then do they proceed to ask every 10 seconds if the order is done? When they hit the 60 second mark do they start screaming at the top of their lungs "I told you I wanted that order in 60 seconds. If you don't have it to me in the next 15 seconds I want my money back and the order for free."?

Do they make an appointment with a builder to contract them to build a new house and go to the appointment with a crayon drawing of the house, and tell the builder they want it done in a week. When the builder says that is not possible, we would have to first do an architecture design, order the supplies, and building the house will take at least 3 months, do they tell him "fine, you can have the rest of the day to do the architecture, tomorrow to get the supplies, and 2 weeks to build the house.", and really expect it done?

When they go for a 15 minute oil change do they tell the cashier they only have 3 minutes to spare, so they need the oil change done in 2 minutes and expect it to happen?

I personally have never seen anything like this out in public, but I see it all the time in my line of work. Why when it comes to software do people think they can tell the person who is making it, how much time it should take? My theory is they have Buttlodgentitus. A severe problem that some how happens on the way to meet with us architects. On the way to the meeting some how their heads get very uncomfortably jammed where the sun does not shine. No matter what you say, they can't hear you. No matter what you draw, they can see it. They just give you their demands and leave without acknowledging anything you have tried to explain to them.

I don't know why this seems to be a such a big problem with the field of software development. But hopefully one day we will find a cure. It would be nice to be like a normal person who is supplying a service, and be able to do it in the time it takes to do it.

The only thing Buttlodgentitus leads to is missed deadlines, buggy code, unsatisfied customers, unsatisfied management, and unsatisfied developers.

Thinking Software Development Process Implementation is Free means the Blind are Leading the Blind, but there are Ruby Slippers that may Help.

These small lists of Software Development Processes are the processes I am referring to in this blog.
Agile- Small teams / small projects at the same location
XP
Agile-Model Driven Development
SCRUM
Essential Unified Process (EssUP)

Formal - High Ceremony Striving for Higher Predictability
Unified Process (UP)
Rational Unified Process (RUP)
Enterprise Unified Process (EUP)
Product Line Engineering (PLE)

Frameworks
Microsoft Solutions Framework
Zachman

What makes people think a Software Development Process can be implemented in an organization at no upfront cost (including time and money)?

Of course the number one culprit is lack of experience. The inexperienced have no understanding of what is involved in process engineering, and they usually have the belief that process is a luxurious overhead that is only to be thought about when there is complete downtime or during hours above billable hours. This same lack of experience also usually leads to the perspective that implementing a process will add hours to a project, and therefore adds cost to every project in the organization that uses a process. If your software development process adds hours to every project you have, it is time to reengineer your process.

I have also run into a lot of people that believe that they have been involved with a successful process implementation. After spending some time talking about their experience, you find that they built some reusable components, made them available to a development team, and considered that process implementation.

Another scenario I have commonly seen is an organization putting a project manager in charge of the process engineering project management that has no process engineering experience. They have worked with in a development process very successful, and they believe that is process engineering experience. What they do not realize is that project management is one of many roles found in a development process, and when in that role you are project managing a development process from with in the process. Those skills obtained while doing that, are not the same skills you need to project manage a process engineering process. This scenario I like to call the blind leading the blind.

There is a lot for a person to learn about software development processes. Actually there is as much to learn about them as there is to learn about programming, architecture, and project management, which are all parts of a software development process. Process engineering has its own set of skills that is above and beyond being part of a software development process. That is one of the reasons Rational put together the Process Engineering Process (PEP) and SEI put together the Software Engineering Process Management (SEPM) Program.

Like a software development process there are different phases, iterations, roles, activities, and artifacts present in a process engineering process. It would stand to reason that a process that creates the environment that allows for the implementation of multiple processes that guide your development teams through the development lifecycle would require a little work to get put in place. There are a lot companies out there that do not understand this.

Also like a software development process there are different process goals found in different companies. Companies developing simple brochureware websites with static HTML pages will have a much different process than one that develops software for hospital equipment. That means the process engineering process will greatly differ when implementing for different types of development.

90% of the companies I am involved with develop rather complex web applications or smart client applications. The development cycles range from months to years. So the development process is usually one that supports instances of the RUP, UP, EssUP, or PLE. The range of development teams within a given organization have range from 5 to 25+ working on separate projects. I have been in organizations that do understand the process engineering process and have allowed for the proper time and allotted for the cost of implementing processes correctly. That has happened approximately 33% of the time.

Many times the ones that do not understand process at all are found in Never Neverland (The Process Ladder- UP, RUP, EUP, PLE, & Never Neverland).

My worst experience is with the companies that continuously plan and talk about process improvement, and plan and talk about process improvement, and plan and talk about process improvement, and plan and talk about process improvement, and then they decide to plan and talk about process improvement.

Imagine if all we ever did was talk about and plan an application. No one did any development. We just had monthly meetings to talk about the application and how wonderful it will be when it is done.

These are the companies that think process will magically appear one day, and it will have cost them nothing. They have no understanding of process engineering, yet they don’t want to hire a process engineer because they don’t understand what one would do. Mainly because they don’t understand what process is, or how much work it takes to engineer one. Some of the companies are changing. It wasn’t too long ago that software architects were not understood, and therefore were not accepted as a necessity. Before the architect, the software project manager had the same problem (Where is my Project Manager?).

My craziest experience has been being assigned to improve the development process across a company of about 10 to 12 development teams, ranging from 1 developer to 7 or 8, working on moderate to highly complex applications. We talked about process improvement for months.

Finally I was told it was go time. They want to use the RUP and PLE where appropriate. I would be given a team of 5 to work with me. I was told we should meet for breakfast, lunch, or dinner every few weeks to do the process. We should be sure to do process work after we have billed our 40 hours for the week. Most of the team did 50 – 60 billable hours a week as it was, so I was sure they would love hearing about their newest assignment.

That was like telling me, we are giving you a team of 5 developers to develop a new system. It is going to impact all our other teams, making them more efficient, and it is going to save the company a lot of money over time. The system is much more complex than the systems you have architected for us to date, so this will be the most difficult project we have given you so far. We think this system should be done by you and your team over breakfast, lunch, or dinner every few weeks. We don’t want you to bill for this system.

Needless to say, process was not improved. Process Engineering takes an upfront investment of time and money. You cannot avoid paying for it initially. I guarantee that if you think you are getting by without paying for it, whatever you are doing that you consider a software development process is costing you much more time and money in the long run than it would to implement process correctly.

For the companies out there that are reading this, I would like to put in perspective where I place the skill set of software process engineering. Most companies understand cost. So let’s use that as the scale. Let us say you want me to be your developer, the price would = A. If you want me to be your lead developer, the price would be A x 1.5. Let us say you would want me to be your architect, the price would be A x 2. I wouldn’t be one, but if you wanted a good project manager, the price would be A x 2. Let us say you would want me to be your software process engineering, the price would be A x 2.5.

But those of you, who are not willing to change and still think process should magically appear for free, you need not lose heart. For $20.00 you may purchase a pair of slippers just like Dorothy wore. I suggest wearing them to each meeting you hold to plan and talk about process improvement. After each meeting you all close your eyes and click them together 3 times saying each time “We just want process for free”. Get your ruby slippers HERE.

SEI SATURN Early Registration is Open

Today I received the invitation for early registration to SEI Software Architecture Technology User Network (SATURN).

Unlike most of the Tech conferences around today, this is not geared towards the marketing of anything. It is the only one I would consider going to. I have had several opportunities to attend Tech Ed, but have no desire to. This one I would love to attend, and will not be able to.

If you are a Software Architect and can get there, I would go.

More info HERE.

The Visual Studio 2005 Software Development Kit (SDK) version 4.0

The Visual Studio 2005 Software Development Kit (SDK) version 4.0 is now available for download.

Screen Shots here.

Get it here.

The Programmer from Hades

In my career I have come across a lot of different types of people. The programmer that blew through my life a few months ago left a trail of destruction in his path that I have been trying to clean up for the past 2 months and will be cleaning up for the next year, and he accomplished 90% of it in his first 4 weeks here.

It all started when I came back to a project that I had previously architected, built the framework for, and lead a team of developers through the first release of. I was gone for a month and in that time frame my company had hired Lucifer (the name we will use to protect the guilty) to replace the lead developer on the project. A young fellow who had my colleagues convinced he was a child genius, who was a previous Microsoft employee, that was into fashion as much as he was technology.

When I met him he had set up his mini Mac, his wide screen (27 inches or so), and was programming on Vista. By the time I got to him, which was his 3rd week, he had refactored our entire code base renaming and moving everything around. Our code base is 3 Smart Client Apps and a Web Site. We have approximately 30 modules that integrate with the CAB. In other words it is not small.

Needless to say nothing worked. I sat with him for a week getting the apps compiling and running again. After that week our client decided he would mange Lucifer himself and did not want to pay for Architectural Guidance on the project anymore. At the same time I told management Lucifer needed to be fired. Immediately before he does anymore damage. To my dismay they still believed he was a genius.

I was out of the loop, and Lucifer was set free.

To make this very long and painful story shorter... 2 months later after never showing up for work, finding out every story he told was a lie including working for MS, and that nothing he coded ran, Lucifer was fired and I inherited his mess.

There were so many problems with the code bases that I requested a tape back up of the code from VSS. We have end of month back ups as well as daily back ups (but the daily BUs only go back 3 months) so I got the code from his first week here. In his first week here he deleted our VSS code base and recreated it under a new project destroying our entire history of the project. Never have I ever seen something so stupid and so arrogant. Changes had been made that month to the original code so it was no good to pull the month prior.

I spent a week going through IL trying to figure out what was on the production servers and the staging servers. After a 3 day migraine I decided to give up and since have been stuck with the messiest code base I have ever seen.

Lucifer has destroyed all our binding sources in all our projects, gutted our constants code, deleted reporting proxies, destroyed a framework we had built and used on the project (in VSS too), made changes to different layers of the code that just simply broke it with absolutely no logical point, had our one application's proxy pointing to another application's web service, removed validation logic from over 7 modules, and told our client prototypes were done that never existed.

That is the list of things I have found and fixed, or am in the process of fixing.

A side note... Our production code that was deployed before Lucifer hit town has been bug free since it's October deployment. Thousands have used it, and we have not received one bug report. Now we can't even get it out of testing done on our development servers. Although that will change in the next 2 weeks (I hope).

The lesson... I wish there was one. I didn't have any control over him, and could do nothing to get him canned and tried several times. Attendance finally got him canned. When along he was doing nothing but destroying our applications.

The lesson for the client... Don't try managing developers when you have no management or technical skills.

The conclusion... Lucifer was either on some really good illegal drugs, or needed to get on some really good prescription drugs.