All in a golden afternoon

Occasional musings...

  • Published on

    The end of programming

    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.

  • Published on

    Art, Music, and Programming... and AI?

    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.

  • Published on

    JavaScript modules for C# developers

    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.

  • Published on

    Let's work overtime

    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.

  • Published on

    Why we stopped using SignalR

    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.

  • Published on

    SOA is not going away

    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.

  • Published on

    Bite-Size Chunks

    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.

  • Published on

    Behavioural Coupling

    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.

  • Published on

    Natural Aggregates vs Synthetic Aggregates

    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.

  • Published on

    Entity vs. Value Object

    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.

  • Published on

    Aggregate Roots vs. Single Responsibility (and other issues)

    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.

  • Published on

    WCF issues

    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:


  • Published on

    Silo, where are you!

    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"

  • Published on

    There is an aggregate root in my soup!

    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.

  • Published on

    Why *I* think software projects fail

    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.

  • Published on

    I cannot know what I do not know

    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.

  • Published on

    Applying CQRS

    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.

  • Published on

    DDD != AR

    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.

  • Published on

    Order.Total(), CQS [Meyer], and object semantics

    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.

  • Published on

    Domain-Events / ORM (or lack thereof)

    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

  • Published on

    Aggregate Roots with a collection of another AR

    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.

  • Published on

    Domain Task-Based Interaction

    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.

  • Published on

    Aggregate Roots as self-contained units

    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.

  • Published on

    Temporal Data Coupling

    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.