All in a golden afternoon

I am concerned about AI and what the impact will be on programmers.

Over the years, there have been many predictions related to the demise of the programming profession.

However, we have never been so inundated with media relating to the subject. It seems as though every other day brings a new "AI is coming for your job" article, post, or video.

I honestly am not worried, at the moment anyway, about AI being quite as disruptive when it comes to programming. I am more concerned that the "programming is dead" narrative may lead to a massive shortage of developers in coming years.

I have long held that belief that programming relies heavily on creativity. This is why I believe AI will have a very hard time competing with humans on creativity.

I don't believe that creativity is something that one can learn.

After watching "Uncle" Bob Martin - "The Future of Programming" I got to thinking about the software industry again. I got to this video via AGILE HAS FAILED. A PEEK AT THE FUTURE OF PROGRAMMING and I'm pretty sure that was again via my daily CodeProject Newsletter.

2024-05-11: I haven't been subscribed to these for years now.

I have decided to make use of DoneJS for my web development. In turn, DoneJS makes use of a host of other technologies. The one that drew me to this environment was CanJS as I had spent some 3 years using Ember.js whilst working for a former employer and I didn't quite like it. After some investigation I decided on CanJS and that led me to DoneJS.

2024-05-11: My current choice for front-end development is Vue.

Yesterday (30 March 2015) I go to a large insurance company for an interview. Some high-level technical questions arise. I could tell that the interviewer is burning to get to something. Then he mentions that he has had to put in 300 hour months and whether I would decline a project on that basis.

My current development team has been making use of SignalR for communication since I came on board 1 February 2013. However, we have been replacing the communication infrastructure bit-by-bit as we ran into issues.

Sometimes it is difficult to explain things that appear to be extremely simple. I guess this is where tacit knowledge comes into the picture. It may very well be that service orientation falls into this category.

I came across this article on ZDNet: The bigger the system, the greater the chance of failure

Now, I am all for "bite-size chunks" and Roger Sessions does make a lot of sense. However, simply breaking a system into smaller parts is only part of the solution. The greater problem is the degree of coupling within the system. A monolithic system is inevitably highly coupled. This makes the system fragile and complex. The fragility becomes apparent when a "simple" change in one part of the system has high ramifications in another part. The complexity stems from the number of states within the system that increases exponentially since they are all coupled.

When I left work yesterday I had to work through a turnstile. One of those big ones that only one person can go through at any one time, in either direction. So it turns both ways. It is secured so I have to swipe my access card to get in or out.

This got me thinking about how that system works.

In databases we have natural keys such as company code, client number, and order number. Then we have synthetic keys that are typically globally unique identifiers (GUID) or auto-incrementing numbers (IDENTITY).

It seams to me that we may need to make this same natural and synthetic distinction when it comes to aggregates in domain-driven design (DDD). The whole Aggregate Root (AR) concept makes it extremely difficult to define certain structures; especially when starting out with DDD.

This is another question that keeps popping up on Domain-Driven Design. It seems to be a difficult task and some of the answers seem to complicate matters since they come from a technical context.

It is interesting to note how many questions there are around Aggregate Roots. Every-so-often someone will post a question on the Yahoo Domain-Driven Design Group regarding how to structure the Aggregate Roots. Now, I may be no genius but there are too many such questions for my liking. It indicates that something is hard to understand; and when something is hard to understand it probably highlighting a larger problem.

2024-05-11: Yahoo groups no longer exist.

I installed a WCF client on a test machine this morning. Since it is using message encryption I installed the relevant certificate in the TrustedPeople store.

When the application started I received the following exception:

X509InvalidUsageTime

I just read an interesting article.

The reason I say it is interesting is that silos have been denounced for quite some time now, and they should be. Yet, here is someone that appears to be a proponent thereof:

"Silos are the only way to manage increasingly complex concepts"

So there was yet another discussion (2024-05-11: link to the chat no longer exists) around value objects and repositories on the domain driven design yahoo group. In this case it revolves around a the definition of a Country.

Firstly, a repository should return an entity; never a value object. Well, so the definition goes. One may want to break that rule but it probably is not necessary. Now the definition of a value object vs. an entity has been rehashed to a point of boredom but another way to look at a value object is a value (albeit a composite value) that never changes. The date '27 April' never changes.

Since the software industry has now been around for quite some time it is possible to look at the statistics around software project failure. Although a great deal has been written and said about software development failure there is probably not too much in the line of anything that can be done about it. There should be.

Sounds silly, right?

But it is interesting looking at something like the Dreyfus model of skill acquisition and pulling that through to software development and what I have experienced over the years. Now whenever there is a paradigm shift one inevitably goes back to the Novice level. The fact that one has been doing something A for 10 years may not count for much when I move to something B. I say may not because A and B may be related, so I may not end up way back on the Novice level.

Whenever a new technique comes to the fore it takes a while for it to settle in. Quite often one tries to apply it everywhere and that is when it seems as though it doesn't always fit. Of course, one should at least try to give it a go but there are instances where it may just not be the right tool for the job.

Command / Query Responsibility Segregation is one such an animal. It may not be applicable in every scenario.

I have been struggling with many aspects of object-oriented development over last couple of years, all in an effort to improve my software. I have, along with others, been trapped in the DDD Aggregate Root thinking that appears to be everywhere. It appears as though there is this opinion that ARs are the centre of the universe and I have come to the conclusion that it must have something to do with the consistency boundary afforded by an AR. This seems to have become the central theme. Almost as though it became necessary to define DDD in some structural sense.

Right, so I have seen some examples of determining an order total by adding the totals for the order lines, and then applying tax, etc. Firstly, however, we need to determine whether an order would actually ever do this. Why? Because an order represents an agreement of sorts and is a near-immutable object. One typically starts out with a quote (or shopping cart). This quote may have items that are on special. We may even apply a certain discount (based on our client segmentation or a discretionary discount) to the quote. There will probably never really be any rules around how many quotes a client may have or maximum amounts or the like.

Now I don't particularly fancy any ORM. I can, however, see the usefulness of these things but I still don't like them. One of the useful features is change-tracking. So as you fiddle with your domain objects so the ORM keeps track and will commit the changes to the data store when called to do so.

Now let's say I create an order with it's order lines. My use-case is such that I have to call Customer.AddOrder(order). That is OK I guess but what about now storing the changes? What were the changes? For each use case I need to have my repository be aware of what to do. Maybe my OrderRepository.Add(order) is clever enough to save the changes

I have been wondering whether an aggregate root should ever contain a collection of another aggregate root. Back to the Customer. Is it OK to have a collection of Orders? One could argue that a customer may have many thousands of orders after some time so it would be impractical. However, such a collection (in the domain) would mean that the customer only has a collection of the open orders. In a real sense this list should never be all that big. Using CQS one may even remove the completed orders from the domain store.

After some interesting to-and-froing on the Domain-Driven Design Yahoo group the penny dropped on task-based interaction. Now this is something Udi Dahan seems to have been doing a while and it is actually very nifty. I must admit that I thought I actually understood task-based vs. entity based interaction but it turns out that even having something like 'Activate Account' is not necessarily task-based. Well, the UI would appear to be task-based to the user but how we implement this 'task' in the domain is where it gets interesting.

There has been some discussion around many-to-many relationships. Here is what Udi Dahan has to say: DDD & Many to Many Object Relational Mapping

OK, I know Aggregate Roots (AR) are a consistency boundary but I believe that they need to do even more. As Eric Evans mentions in DDD that relationships need to be scaled down to simple forms or even eliminated since it leads to simpler software. I agree.

I spent some time this past weekend thinking about how the object-oriented development community has done its utmost to rid itself of high coupling within object models. It has, for the most part, been rather successful.