Dave Laribee - All Comments

A Response Concerning Semantics And Intention Revealing Code

new ThoughtStream("Derick Bailey"); — Fri, 19 Mar 2010 18:17:01 GMT

My previous post talked about some code that was using a null value to cause certain behavior. The general

Field Vs. Property: Does It Really Matter?

new ThoughtStream("Derick Bailey"); — Thu, 04 Mar 2010 20:27:49 GMT

Given my recent experiences with Ruby, my cursory knowledge of Java, and my past experience with past

re: The High Cost of Losing a Developer

Me, myself and I — Thu, 04 Mar 2010 10:03:25 GMT

Replacing a programmer is, in terms of costs, a matter of how well you are prepared to do so. Most successful manufacturing companies have some spare parts and spare machinery on stock, in case something breaks. They also have a clear image of what part and what machine is deployed where, and what it does. They have no trouble reconfiguring the assembly lines for when production demands it. Unfortunately, most programming companies, even large ones, don't ever make plans for loosing a programmer. Clearly the costs associated with this event are higher in such companies than in companies planning for this. And it is unreasonable to assume that just because you try to make your employees happy they won't leave. What if one dies in a car crash, wins the lottery or marries and moves to another town?

On the other hand, if you put no effort into keeping your programmers happy at all, it is likely you already only have crappy programmers. Replacing a crappy programmer with another crappy programmer won't do that much harm. There's an article about development seen as a big ball of mud here: http://www.laputan.org/mud/. I don't think that in such a situation replacing a programmer is much of a problem - things already run so bad that it's difficult to make them run worse.

@Rubio: usually, when we hire somebody, we allocate two weeks for productivity zero, the rest up to one month for some introduction, the rest up to three months to getting him where he can do simple things on his own, and the rest up to one year before he can do things without supervision. Any other planning would mean higher costs. A new, inexperienced programmer delivering working code that isn't up to quality standards causes work for another programmer, and adding up the costs it is cheaper to have the inexperienced programmer do simpler and less work than to have him swamp other programmers with work.

Web Design West Palm Beach

Web Design West Palm Beach — Thu, 25 Feb 2010 15:29:47 GMT

re: Low-Technology

air jordan — Tue, 23 Feb 2010 03:21:50 GMT

colin - excellent observations. i've been mulling some of the great comments here over and kind of centering on your analysis (though not so pithy and straight to the center!). so many times it's just damned fundamentals and OO isn't even the start. it's coupling and cohesion which have been around since structured programming days and implicit even in cards (!).

re: Ayende on Advanced NHibernate

air jordan — Tue, 23 Feb 2010 03:10:18 GMT

25wtewet256263 3tw3562

re: The High Cost of Losing a Developer

Rubio — Mon, 22 Feb 2010 08:34:33 GMT

Great article.

Dave, care to blog about the time required to break in a new developer? I'm having, once again, trouble convincing management that it takes at least 2 months before a newly hired developer is productive.

re: Folder != Namespace

Eric Duncan — Tue, 09 Feb 2010 16:23:59 GMT

A different view...

There are two approaches I take to namespace/folder arrangements for the projects I architect, and I apply DDD-logic to define them.

* The first is discoverability (for new developers).

* The second is Aggregate Root groupings.

These two combine to give a really nice and neat namespace convention we are mostly now. So, let's look at an example, starting with DDD logic (define the ambiquious language first)...

A current client has two different user types: Coaches and Athletes. There are also regular users that can signup and comment. Therefore, I really have almost 3 user types. But since all user types can signup and comment, that means I have a common root element: User. To define the additional suer types, we will inherit the common User root object into a CoachUser and Athleteuser object. The reason being that the new user types will have additional repositories (tables) that will be persisted and massaged.

Now that we have defined the common boundry 'User', I may create the following file and folder structure:

/Users/

/Users/AthleteUser.cs

/Users/AthleteUserService.cs

/Users/AthleteUserRepository.cs

/Users/CoachUser.cs

/Users/CoachUserService.cs

/Users/CoachUserRepository.cs

/Users/User.cs

/Users/UserService.cs

/Users/UserRepository.cs

/Users/IAthleteUserService.cs

/Users/IAthleteUserRepository.cs

/Users/ICoachUser.cs

/Users/ICoachUserRepository.cs

/Users/IUserService.cs

/Users/IUserRepository.cs

Notice the namespace, /User/. This means whenever you are dealing with any type of user interaction, you have a namespace of Project.Users. Therefore, the discoverability for junior developers, and testers, is straightforward. They can inspect the Project.Users.* namespace and know everything available.

Also, not shown, but the AthleteUser, AthleteUserService, and AtheleteUserRepository would inherit User, UserService, and UserRepository respectfully - therefore giving you all of the underlying User properties and methods. This is important; because, you do not want to have to call IUserService to save a user, and then call IAthleteUserService to save something specific to AthleteUser. Instead, your UI would simply deal with IAthleteUserService for any features that are specific to Athletes (such as their sports profile). Have the sistuation where you have an AthleteUser, but you are only dealing with basic User functions? Simple, cast down to User for everything you are doing in the UI that is just "base user" specific.

re: The High Cost of Losing a Developer

Nike — Fri, 08 Jan 2010 06:12:36 GMT

Nice information, valuable and excellent design, as share good stuff with good ideas and concepts, lots of great information and inspiration, both of which we all need, thanks for all the enthusiasm two sacrifice such helpful information here<a href="http://www.finalfootwear.com">.</a>

Social comments and analytics for this post

uberVU - social comments — Fri, 18 Dec 2009 20:50:03 GMT

This post was mentioned on Twitter by lazycoder: Why entities shouldn't have setters. (by @laribee ) http://bit.ly/CGgSL

re: The High Cost of Losing a Developer

Kevin Rodrigues — Thu, 10 Dec 2009 08:55:53 GMT

It is true that a good developer should be retained. The trouble arises when the retainment involved increase in the pay packages. The managemetn often does not see the value that a good developer can bring to the organization. And quite often settle for another developer at a relatively lower cost and lost of productivity (which according to them is not that difficult to obtain if knowledge sharing is possible).

re: Transitioning from NAnt to Rake

artiste peintre — Tue, 08 Dec 2009 22:13:21 GMT

I am interested in the topics discussed but have been feeling a little intimidated by the thought of the work.

re: Domain Model Overuse

Gabor de Mooij — Thu, 03 Dec 2009 08:21:05 GMT

Sorry. I mean the anemic domain model is an anti-pattern, but only if you are trying to implement a domain model. You can work with plain value containers and transactional scripts, that is just fine. Domain Models can be quite handy if you need to manage complex systems. The alternative is soft-coding or scattered logic in many different controllers. I guess the value of having a DDD grows as your project gets bigger.

re: The High Cost of Losing a Developer

frustrated manager — Wed, 02 Dec 2009 20:39:41 GMT

It depends on your company/domain you work in. Most developers these days are incomponent at any price level other than peanut levels. Most "legacy" systems these days were built by morons in the dot com era and the developer industry still hasn't shed them yet. The amount of technological debt that most companies retain probably outstrip cost of the all the middle eastern wars + the recession we entered.

re: The High Cost of Losing a Developer

Marcel Popescu — Wed, 02 Dec 2009 19:42:40 GMT

@scott: " The biggest investment, as you rightly state, is dedicated time."

Very much agreed. I'm from Eastern Europe, I invested at least 10 hours a day in programming since I was 12. (I am almost 40 now.) It is quite annoying for me to see that the "cheaper" programmer in your story earns a lot more than I do :)