Author: bryan

Categories
Business Technology

Enforcing DDD

So you’re all excited about TDD by now. You’ve also hooked into DDD and cutting your teeth on some of the more progressive methods for delivering software accurately, and, fairly rapidly. And with time, you probably need to start leading a team in DDD. Or you just need to interface with a team but want to make sure everyone’s on the same page. That is, the last thing you need is DDD-mutiny…. 🙂

We were putting the domain together and started adding in the NHibernate mapping files. One of the many beautiful things about NH is the ability to generate the schema based on the mapping file data. Now, strictly speaking, the database is not all that important from a design perspective. At least, that is, not initially if you try remain true to your DDD-allegiance. Anyway, this post is not about all that. This post is about enforcing DDD and one of the things you might want to do is remove the temptation to do some fundamental ERD analysis during the domain design. And if you don’t want to, then don’t 🙂

So how’s this for aggressive and extreme?

<?xml version="1.0" encoding="utf-8" ?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">

    <class name="NHibernate.Examples.QuickStart.User, NHibernate.Examples" table="[2239987-9382WED-23D23]">

        <id name="Id" column="[LKJDSA-98DSJHDS-9D76SD]" type="String" length="20">

            <generator class="assigned" />

        </id>

        <property name="UserName" column="[130SF98-08JDY-98BNXDS]" type="String" length="40"/>

        <property name="Password" column="[10DDD398-08EFHJDY-98CVBDDS]" type="String" length="20"/>

        <property name="EmailAddress" column="[1098-0KHS8JDY-98DDDS]" type="String" length="40"/>

        <property name="LastLogon" column="[10998HG-08JDY-98DS]" type="DateTime"/>

    </class>

</hibernate-mapping>

You get the idea? And replace those funny column/table names with GUIDs for extra spice. Or even better, random base64-encoded strings. Of course, you can write a script to generate random table and column names for all your mapping files in a release build if you’re not comfortable with the idea of a “random” database schema during development.

Imagine trying to decipher the following while debugging:
select KJHDSA-AS878, SL-983LD23-2J FROM ASLKAJS8-32JH INNER JOIN ASLOE-876-35 ON DAS-3FE-43 = 321JDH-8786 WHERE ALOYWI-9876D = 2

For me, the bigger question would be: why are you trying to debug the SQL when you’re effectively abstracting that part of the solution and ‘supposed’ to be treating it like a black box?

But before anyone gets me (too) wrong, I’m not suggesting this as a standard practice, just a far-out idea which opens up some possibilities for managing DDD adoption 🙂

Categories
Business Technology

Overdone

Following up on the theme of overtime, voluntary or otherwise, there’s another good reason why it’s counter-productive. In a team environment, all it takes is one person to work that little extra bit on a regular basis, and because everyone’s capacity is inter-dependant, that extra workload starts to catch up and takes it toll.

For example, imagine a business manager getting more leads than hours in the day to follow up on.

Developers producing more code than hours available to test.

Testers reporting more bugs than hours available to fix.

Analysts churning out more requirements than there are hours to spec.

Might not be such a bad situation, but one of two things end up happening. Everyone catches up at an unnatural pace, or the pace-setter gets bored or frustrated because the feedback cycle is taking too long- for them.

Estimates become unreliable, planning ends up hazardous, at best, and a false sense of productivity starts to pervade the project. But it’s not all gloom and counter-productive. It only really becomes an issue when the feedback gap gets too wide. And that’s where methinks the heart of most productivity, and certainly learning issues lie: the length of the feedback cycle. But that is a book on it’s own 😉

Categories
Life perspective Rants

Common Sense

there’s nothing common about “common” sense…

Categories
perspective

Exams

Uhuh… it’s that time of year again and exams are on the go. Now, at the beginning of the year, i was enthusiastic and was really looking forward to taking on all 8 subjects (part-time). 😀 Aight, turned out a little too ambitious, and i ended up dropping one a third of the way into the year. But then i sat with (am sitting with) 7. Hectic. Although, i’m glad i set an ambitious goal ‘cos, well, like the saying goes: “aim halfway and you just might get there” 😉

Anyhow, got Calculus coming up in a couple of hours. I got derivatives and integrals pouring through my brain- and i sure do hope that my head holds out until next week. One thing though… these exams, besides the actual increase in mathematical knowledge, have been filled with lessons, namely:
* take big chunks out of life
* and then don’t be scared to spit something out if the chunk really was too big
* you’d be surprised at what you end up handling vs. what you thought you could handle
* don’t delay your dreams for too long, as Jack would say, don’t let your dreams stay dreams.
* have fun

But then some revelations, more than lessons… and the real support for undertaking all the above. Without Lolly telling me to “go study” or being patient (smile and nod) while i rambled on about inductive proof or just making that cup of tea when i really needed it… indeed, the real prize for me is being able to just get through it and experience a lot of lovin’ in the process.

Of course, you also need to consider that “life” doesn’t stop either… the plumbing breaks, the interest rates go up, babies get born, jobs change, the house needs fixing, anniversaries, birthdays, community commitments; all that goes on “as normal”. And just getting through it all, in one piece, well, that’s *almost* prize enough. Which doesn’t mean i’d be happy if i didn’t pass any papers! 😀

Some things stretch and test you in ways you never imagined… and it doesn’t have to be a degree or a couple of exams… but being part of that process really adds *something* to everything, without ever being _that_ important on its own. And that, for me, is key. Nothing seems to have much significance on it’s own. It’s the space in which that thing contributes where learning, loving and living takes place.

Categories
Business Technology

TDD, Functions and Design

A function assigns a dependant variable (the range) to an independent variable (the domain). Alternatively stated, a function will assign a result to an argument. And by that definition, we eliminate “void” methods and properties since these have neither range, nor domain. It is accepted though that these constructs can still alter the state of an object, but the focus of this post revolves on Functions and TDD.

This definition is useful since it also helps to describe bug resolution as a function, or more accurately, as an inverse function. An inverse function is determining the inputs based on the outputs. So when we’re resolving bugs, we’re inverting a particular function. So let’s look at releasing functionality in software…

We implement a function, with both range and domain. At some point in time, that function starts to behave “unexpectedly”, ie. it’s buggy. Functionally, either the range or the domain of the function has contradicted expectations. And the more granular the function, the greater the likelihood is that the domain introduced the bug and that the range is symptomatic. Of course, this can change as the implemented function increases in cyclomatic complexity. But back to TDD…

TDD recognized the domain-range behaviour of a function and attempted to introduce a mechanism whereby the domain-range relationship could be documented in an automated fashion. In doing so, a programmer could efficiently determine where the system changed expected behaviour as the domain and range of the various functions increased through integration. The programmer was then empowered to make empirical-based decisions, quickly, and in doing so progress (hopefully more rapidly) towards completing the various functions. Or at least, that’s the way i always understood it….

Then a school of thought emerges asserting that TDD is more about design, and not testing. And while it is acclaimed (and true, imho) that TDD will bring about a better design, it is still more about testing than it is about design. TDD documents what the expected inputs and outputs of any given function are, and the relationship between the range and domain. When it starts to focus on design, or is utilised with design as the primary focus, it’s no longer TDD, but should be rephrased: Perspective Driven Design, or User (as in caller) Driven Design. In which case, xUnit frameworks, tools and processes are inadequate. Why indeed would statements like Assert.AreEqual() be required to check wether the _design_ works? It’s not, and as such, TDD fundamentally remains, and should always remain, functionally oriented.

Along with TDD come some well understood concepts like defensive programming, as an example. DP has nothing to do with design, but everything to do with functionality. Of course, DP can come without TDD too 😉 But it still remains that TDD is about testing the function, not the form. And wether the form evolves into a good design or not, depends on the programmer. TDD won’t guarantee you a good design. You can still hack it. And it also won’t guarantee you good function either- you can easily write pretty bad tests.

Stick to proper design principles outside and beyond TDD and intelligently utilise a combination of experience, technology and common-sense to get it looking right. And use TDD, primarily, to get it acting right But try not confuse the two…

Categories
Life Technology

Like A Simile

We use similes and metaphors quite frequently, particularly in software. Everything is so figurative and you spend all day coming up with names for things that are “like” real world objects. Of course, that’s not counting those things which are not like anything else other than what they are in software. This is not about them. And this figurative language we carry over into customer engagements too, explaining to our dear customer why the original quote does not hold since they subsequently added the kitchen sink and “tinted windows” 🙂 Not to mention explaining why that takes an extra ‘x’ weeks.
During one such session, it suddenly dawned on me halfway through the metaphor, that the client started extending the metaphor and the proceeded to re-apply it back to the software project, taking it too literally, and ended up explaining to me how software works based on the metaphor at hand. Doh! And all i was trying to do was help educate and understand…

I think IT, in general, has come under heavy pressure to talk the language of the client- and indeed, we are encouraged to keep getting better at this. Make it more accessible so that they understand… Why?

I don’t understand that thing my dentist uses to fill a tooth; nor do i care about the gadget the plumber used to seal the pipes with; and yay for the structural engineer who … well, i really don’t know what he did. But i still use and pay for their services. Did they go to great lengths to explain the intricacies of their tasks? Nope. Did it matter. Not really. I engaged them- they told me how much and how long- i paid, they did it. Moving right along.

I think the more we “passively force” non-programmers to understand what we’re doing, the more confusion we sow. Particularly when the metaphor we use is so accessible, we have no idea how their experiences, assumptions and understandings will impact on the point we’re trying to convey.

As programmers, we owe it to ourselves to forge the language (jargon) we have created, not with the purposes of creating a divide, but so that we can just get on with the job, efficiently. Without the extra fluff. Of course, that’s not to say don’t make an effort to help a client understand, if they want to understand on technical terms. Dumbing it down doesn’t really help, except maybe in polite social discussions 😉

Jessie, aka Beanie

the miracle of growing is something else! watching Jessie grow is just, well, yeah.. wow. i could wax a compendium of lyrics and still not get close. just everything about discovery: from being fascinated by your own feet to the discovery of laughter and expression. quite something else actually. so far removed from the rat-race yet so accessible. we find we can happily spend the entire day just “playing” and engaging… ah man! what a blessing!

Latest snapshots

Categories
Technology

Software is Hard

You may have heard it before, and if you haven’t, you need to understand that. Besides all the technology and implementation caveats, competing frameworks and myriad and variety of business rules within the same vertical, there’s also the challenge of finding competent resources.

Coding is the easy part. Almost anyone can do it, given enough time with a “Learn _INSERT_LANGUAGE_ in 24Hrs” and a off-the-shelf PC. Even better, do a condensed one year course and come out the other side “qualified” and even better, command a “qualified” salary. What ludicrosity!

Now that’s not to say one year condensed courses and self-taught programmers are to be frowned upon. Some of the better programmers i have worked are self-taught. What you’re not, as a self-taught, or one year crash course graduate, is qualified. Far from it. And then even 4 years into your career, and some candidates reckon they’ve seen it all: they’re intermediate, looking for a senior post (along with the salary). Inconceivable.

Yet, this is what seems to be the status quo in South Africa right now (or at least, that is, in Cape Town). There is a massive demand for C# programmers (in particular) and the demand has outstripped the supply so greatly that the market is flowing with inexperienced skills demanding (and sometimes getting) the outrageous salary demands they’re placing. And the only reason they’re getting it, imho, is that whoever’s hiring them a) are not concerned with quality b) haven’t a clue what they’re doing or c) are really doing so well financially they can afford the risk. And maybe have a secret to mitigating that i don’t know about…

Of course the greater danger is the software that is out there. And then the pervading negative experience in bespoke software that continues because a bunch of “senior” programmers couldn’t get it right.. Go figure.

Two prominent cases recently gave the issue some visibility. The traffic registration system and the online tax filing systems. The traffic department came to a grinding halt for literally weeks because of concurrency issues on the system. The online tax filing handled well enough during the pilot, but when it was opened to the public, it hung. Badly. And we’re not talking about millions of hits per day either…

Until you’ve got about 7yrs of pure development experience (as a guideline, not a dogmatic rule) i don’t think you’re qualified enough to even contemplate leading anything. Stick around for a bit, get some more diverse experience and when you start approaching 10 years in the trenches, maybe then consider grooming yourself in preparation for more of a leadership role. Until then, you’re ultimately only bluffing yourself. Of course, it doesn’t help that the market regards a one-month MCSD as a competent programmer. It just makes it easier to sidestep your own professional integrity.

Please note, the actual number of years is a guideline and, as with everything, there is a lot more to consider than just historical “age”.

Categories
Business Life

An Agile Environment And Ergonomics

A good working environment is essential to ensure productivity in any project, even more so in an agile environment where the pace can often be quite steady, without reaching burnout. A couple of tips…

1. A spacious desk. You can’t have too much clutter or you will get distracted.
dscf0347.JPG
2. A gym ball instead of a chair. I’ve used one for many years now and much prefer it. It also helps avoid the programmer’s hunch.

dscf0345.JPG

3. Dual monitors. A luxury, i must confess, i’m still trying to get used to.
dscf0338.JPG

4. Stationery! No desk would be complete without much needed pens, markers and post-it notes but an arm’s stretch away.

dscf0333.JPG

5. Trash can. Not the virtual kind, but the real kind. Those post-it (and outdated technical specs) notes need to go somewhere, eventually.

dscf0343.JPG

6. And last but not least, the PC. Tucked away and out the way.

dscf0342.JPG

And that’s it. Oh, and one word of warning. If you ever have the urge to sneak hand-cream onto the ear piece of any of your colleagues’ phones… embrace the revenge 😀

Guys, you know who you are… outstanding job! Seriously. This is going to be a hard act to follow, but i relish the scheming 😉

Categories
perspective

Winter of Content

This is why living in Cape Town (South Africa, actually) is sooo worth anything. We have these amazing indian-summer-meets-winter days.. oh yes. This is winter, folks. Hardly the Cape of Storms, although, don’t be fooled, we have our fair share and this year has been exceptional. But then there’s this…
paddleout.jpg
and then…
riding.jpg
and … ahhhhh
turn.jpg