00000000-0000-0000-0000-000000000001 Guid Fun
-
I've browsed this site for a while but have never really had much to contribute. I've been a developer for a number of years and on numerous projects so have seen a lot of crazy code, but since being at my current place of work since January I feel I could pretty much write a WTF book.
I'll start with a quick overview of the team. I joined as a contractor to work on a green field application that is about as complex as a 20 piece jigsaw. It's a small team with a Project Manager, Lead Developer, and another developer. Both the PM and lead dev have worked at the company for numerous years on a legacy C++ application that has become monolithic and difficult to maintain. They have had very little experience with software architecture, and almost no .NET experience which is what we're using to develop the system with. I think this is the root of the numerous problems we have suffered, and after four months of development we are still very much at square one and banging our heads on every wall we encounter.
Our Lead Developer kicked off some Web Service code a few months ago. He created a GetScreenDetails() web method that was apparently very useful as it contained almost everything you could ever imagine - a nice large hierarchy of objects named as xxxDetails this and xxxHeader that. The idea that drove him to do it this way was for efficiency and speed. If you only need to call the Web Service once to get back a representation of the entire database then surely that will save a lot of time, even if you only need a small subset of that data. The mass of Detail and Header objects was said to be a result of using the Web Service Software Factory. Need I mention that there was absolutely no regard to validation, security, or even logic within this Web Service, but I'm sure the motivation behind all that was to keep performance up...
I could go on down that road but would be here all night. I could mention a number of scenarios where the Lead Dev has used the saying "We can't do it that way as it's not SOA". For example, "We can't have an object model because it's against SOA", "We can't use a framework because it's not SOA" and "I really have trouble understanding simple programming techniques so they must be against SOA". After four months of this I did lose it for a few seconds in a meeting and had to draw him a diagram with a few squares.
Anyway, on to the WTF I had planned to mention. It all started a few weeks ago while talking about GUIDs. We have a rediculous physical architecture requirement from the Project Manager and Lead Developer that means we will be deploying the Web Server and Database within 2400 on-site locations instead of having a central server farm - apparently it will save costs. We have now managed to convince "The Dictatorship" that we need an object model, and due to the distributed architecture the developers were in agreement that unique id's would be wise. Our Lead Developer had other ideas. He was adament that we would create all id's from a composition of SiteId and UserId. We were amazed at this notion as you can spot the flaws from a mile off. You can guarantee that an id composed in that way isn't likely to be unique across 2400 databases, not to mention when we start creating PDA variations of the software and such. When we confronted him about the issues he refused to listen, slammed his laptop shut, and went off in a huff. He was in a huff all week. When he calmed down he spoke to a Microsoft Development Consultant that visits us regularly, and then confessed to me that the Consultant had agreed Guids would be a good choice in our situation. Despite this he was adament we would do it his way despite conflict from the whole team. We started using Guids regardless, which is fortunate as he has now adopted the idea as his own.
This brings me to the events of today.
After four months of making us create rubbish they finally spent a week in meetings with a consultant to realise it had all gone wrong and we needed to start from the begining. After a week they came up with the idea of an object model. I myself have been developing OO applications for many years, and so has a new contractor who has now been taken on. Despite this "The Dictatorship" have stated that there will be no design by committee and the task of designing the object model will be by them. This is fine as it is very easy to learn how to create object models in a single day when you have the help of a Microsoft Consultant. In reality the consultant created a fairly good object model to start off with, but they felt the need to spend a week in "improving" it. We were due to start implementing it today so the three of us developers reviewed the model.
It was pants.
I don't think I can summarise it in a clearer way.
Any criticism of the object model is frowned upon and could likely result in job loss. The object model can not be implmented in it's current state. We decided the best course of action would be to implement it anyway just to prove it won't work. Still, we had a major hole in functionality so needed to try and confirm what a "Transaction" object was and a "Reason" object. Another developer e-mailed "The Dictatorship" to ask a couple of questions that amounted to "How the hell is that supposed to work?". We got back something even more illogical than we had inticipated. The Project Manager e-mailed back a one line answer to all the problems - We will be passing around "Known GUIDs". Shortly after that an e-mail from the Lead Developer stated that we will be using "Reserved GUIDs", for example 00000000-0000-0000-0000-000000000001.
It occured to me at this point why we were having such stupid arguments about unique id's the other week - these people really cannot grasp even the simplest of things. I emailed back with a few questions in the hope they could explain their reasoning. Two minutes later there was chaos. An immediate meeting was arranged to help us developers understand their so called flawless design. We were told exactly how to implement a part of the system using these known Guids, although apparently it's obvious. The client will have a config that has a list of known guids. Each guid represents a part of the system. Every web method is to have this guid passed in so that the generically named methods can differentiate and carry out the appropriate task. These guids will additionally be maintained in the database so that the server understands what process to undertake when a generic method is called. Is that clear??
The icing on the cake occured shortly afterwards when I got back to my desk. Prior to the meeting I was sent an e-mail reply by the Lead Developer regarding my queries on the design. It read as follows, "If he's confused about this then how will he cope when we get to the next part of the system". I forwarded it on to the Project Manager, copied the Lead, and said "I believe you were the intended recipient." The Lead then went and hid in shame for half an hour and then made out he wrote "he" instead of "you" on the e-mail that he said was really was meant for me (digging a hole). I told him that it was irrelevant anyway as in no way am I confused over the situation.
I have never worked in a team that has been set up to fail so hideously. It's a good job we have three and a half years to develop this system that should really be created in 3 months. I think it will need three and a half years, especially as I can't see the developers being around for that long.
-
Your Lead Developer is going to cost the company a lot of money. His superiors expect development to be expensive, so they probably will never entertain challenges to the design.
Every time you observe a long-standing design mistake in a product and it makes you wonder why no one ever bothered to fix it, chances are good that someone's ego demanded it stay in place.
-
@VGR said:
Your Lead Developer is going to cost the company a lot of money. His superiors expect development to be expensive, so they probably will never entertain challenges to the design.
Every time you observe a long-standing design mistake in a product and it makes you wonder why no one ever bothered to fix it, chances are good that someone's ego demanded it stay in place.
True, dat.
