Search Results

Search found 3 results on 1 pages for 'taylorotwell'.

Page 1/1 | 1 

• Who should determine team size?

  - by TaylorOtwell

  Developers, managers, or customers? I was recently involved in a situation where I felt like the customers were arbitrarily demanding for more developers on a team which already had too many developers. They were scared the project was going to be late (and it probably will be). Personally, I was scared we were going to fulfill Brook's Law. The group of programmers already lacked in-depth business knowledge, and some were even new to the technology (.NET), yet the customer wanted to add more developers who had even less business knowledge. The impression was that this would make the project get done quicker. I started wondering if the customer, who is extremely bright, but presumably knows little about IT project management, should really be the one determining team size.

  Read the article

• How do you keep SOA DRY?

  - by TaylorOtwell

  In our organization, we've shifted to a more "service oriented architecture". To give an example, let's assume we need to retrieve a "Quote" object. This quote has a shipper, a consignee, phone numbers, contacts, email addresses, and other location information. In other words, a Quote object is made up of many other objects. So, it seems like it would make sense to make a "Quote Retrieval Service". In our situation, we've accomplished this by creating a .NET solution and writing the service. The service API looks something like this (in pseudo-code): Function GetQuote(String ID) Returns Quote So, so far so good. Now, when this service is consumed, to keep things "de-coupled", we are creating essentially a duplicate of the Quote object and mapping from the QuoteService version of the Quote into the consumer's version of the Quote. In many cases, these classes will have the exact same properties. So, if the Quote service is consumed by 5 other applications, we would have 6 definitions of what a "Quote" is. One for each consumer, and one for the service. This feels wrong. I thought code was supposed to be DRY, but it seems like our method of SOA is forcing us to create tons of duplicated class definitions. What are we doing wrong, or is the code duplication just a "necessary evil" of SOA?

  Read the article

• Is there any benefit to obsession with making code "look pretty"?

  - by TaylorOtwell

  Sometimes I spend ridiculous amounts of time (hours) agonizing over making code "look pretty". I mean making things look symmetrical. I will actually rapidly scroll through an entire class to see if anything jumps out as not looking "pretty" or "clean". Am I wasting my time? Is there any value in this kind of behavior? Sometimes the functionality or design of the code won't even change, I'll just re-structure it so it looks nicer. Am I just being totally OCD or is there some benefit hidden in this?

  Read the article

1