Moving
09.03.08Filed Under: blogging with 0 Comments
The time has come, the Walrus said… Not moving very far, but consolidating the technology and personal ranting all into one uber blog. New location (location, location, location) is http://bryanallott.net/blog/. Updated feed URL (http://feeds.feedburner.com/bryanallottnet)
IT “Industry”
22.02.08Filed Under: opinion, programming, technology with 0 Comments
I say “industry” but there’s no real regulation put in by the government (at least here) which keeps the industry in check. For one, it’s not illegal to provide IT services or build software without a licence, while in more established industries, it is illegal to, for example, provide medical, financial, engineering or manufacturing services (where people’s lives are at risk) without a licence. Anyway, that’s not a formal classification or rule, just an idea that appeals to me. Why the necessity to make the distinction?
Over the last decade of building software, i’ve seen a fair share of hair-brained ideas. I’ve also seen some brilliant ones. What i haven’t seen much of though, is brilliant management. I’ve seen some, but these generally come from the business-oriented bunch who just happen to end up in IT; very rarely from tech-savvy management trying to keep a business going. In fact, most of the time, tech-savvy management who try to run their business without business-focused partners end up either working way too much overtime (work = life =work) or going belly up. Somehow, there exists this hype perpetuated by punctuated newsworthy stories of geeks-in-a-garage-cashing-in. So if they can do it, why can’t we? ‘Cos not every story turns out that way.
And particularly software. Manufacturing, distribution or sales, whether it’s IT or food, is the same thing, mostly. That is, the science and art of management has been established and the discipline is well understood. Software, on the other hand, doesn’t fit the mould. Yes, it’s plain manufacturing, distributing and selling, but therein lies the rub. You approach it with business fundamentals, and it works, but if you don’t adapt some of those implementations; you get left behind- and quickly. You toss out the fundamentals in order to keep up; you get dropped behind- even quicker.
As an example, my last company just liquidated. There are lots of different stories as to why, how, when, where or who. Bottom line, no more business. I can only comment on the software aspect; not the rest of the operation. So the only thing i do know is that it was very tricky getting the software strategy just right. Everyone pushed and pulled and chewed on this one all the time trying to get it to work. Maybe, with a little more time, it could have worked out ok in the end? Next time 
More evidence supporting the notion that “software is hard”. And it makes me wonder how different things would be if you had to be officially licenced/qualified, by law, to operate in providing a software writing service. Not a fly-by-night programming course. Not a dummy’s guide to programming. Something professionally trustworthy and legally accountable. I wonder just how far would that go towards stabilising the “industry”? Make it more reputable and have governing bodies presiding over fair exchange between vendors and clients; also ultimately curbing the number of software businesses that just don’t make it.
Neh. Where would we be without the hype? It’s part of the magic of this little world 
Crack My App
21.01.08Filed Under: opinion, programming with 0 Comments
What do you do if someone asks you to do something illegal?
Of course (and i do sincerely mean and hope, “of course”) the first response is to just say “No”. But does it end there? Maybe it depends, maybe it doesn’t?
Well, I was asked by a company to crack some software. Everything was totally illegal and i declined, of course. But as i sit here thinking about it, revising my study module on business ethics, i wonder if just declining is enough? Should i actually report it to the authorities?
If someone asked me to go steal a car, i would definitely report that to the police, after carefully and probably politely removing myself from the company of the requestor.
If someone asked me to steal some money, even if it was money owed to them, i think i would also probably alert “someone”. But if someone asked me to crack software (because i can since i’m a programmer- or at least, that is the assumption), whom do i tell? Do i even need to? Nothing illegal has happened.. but just where does the line end?
Grrrr. Why do idiots want to crack stuff anyway? Just play by the book and it’ll be easier for all of us
Ruby Nuby Catch
08.01.08Filed Under: OSS, programming, ruby with 0 Comments
I was reading up quite a bit and getting a project on the go with Ruby and Streamlined. Perfect for an admin console and mass data capture application. But in my zeal and learning curve, i kept bumping my head against habtm relationships not really working. It was acting weird, and depending on when you pick up on the glitch, you’d explain it a dozen different ways.
Short story long, i scoured- found folk with similar issues and put it down to “bug”- but not convincingly.
And then i was reminded: habtm tables don’t need a surrogate primary key for ActiveRecord development! Doh! changed my associative table scripts to include :id => false and it all works like a charm!
Now if i can only find those threads again and post the “solution” there… Arrrrgg..
But here’s a fantastic post/tutorial on the issue by Sam Aaron.
Recycled Software
27.12.07Filed Under: .net, opinion, programming, technology with 1 Comment
What’s up with everything being ported to .NET? There’s nothing more boring than copying somebody else’s idea, unless of course, your own ideas are pretty crap
And (sup)porting a dozen applications to be used with the .NET framework surely cannot be considered as innovative either- it’s real name is “market strategy”. I must confess though, we’ve (that is, i) benefitted much from having tried and trusted Java libraries (example, NHibernate) ported across, but i’ve also wondered many a time, why not just use Java then? And now emacs.net?
An aside, what i loved about the marketing around NHibernate is that it builds on the solid reliability and legacy robustness of Hibernate in a Java world
But it’s all just recycled software ideas and methinks a large pop of the lemming community are looking for “innovation” in all the wrong places.
<warning>Massive Generalisation About to Occur</warning>
Software developers are more into being “advertained” (advertisement + entertainment) than any other population group i know. Trouble is, i always presupposed we’re more critical than most. But perhaps we’ve reached a point where we’ve started buying into our own hype? Afterall, we can make it fly with words like interoperability, multi-platform and integration. Oooooo… :p
Quality
26.12.07Filed Under: agile, opinion, programming with 0 Comments
Much has been said about quality of software, and even more attention has been given to it. Further, a lot of methodology, and general how-to-do-stuff from project management to code implementation, even design and testing is focused on quality, including the ubiquitous “best practices” and framework collections out there. But then it struck me. All the software i “actually” work with is buggy.
It’s good enough, get’s the job done and i live with it, mostly. And like any good web-theme, the software will be replaced (read: recycled) soon enough, so why the big fuss about quality anyway?
If you got a good idea, get it out, sort the bugs out later, and if your idea is any good, you’ll break even before you manage to iron out most your major bugs, by which time it won’t really matter anyways. Uhuh, i hear a lot of “but that won’t work with real business software”. Really?
How many projects you code, pick up, migrate, port, patch, fix, debug or rewrite because business was complaining that they were (now) “too buggy”? But they were using them, right? And probably surviving pretty well with the “broken software” since now they can afford a software team to code, pick up, migrate, port, patch, fix, debug or rewrite. And the job would be done “ok” except that now, quality is an issue.
Reactionary management has a lot to do with it, but it leads astray and breeds a buzz which forges a plethora of blogging on delivery quality, all under the guise and good name of “it’s what the customer wants”- which they do. But not actually :p
When last did you use bug-free software to pay the rent?
Disclaimer: naturally, this is not a call to “down with quality”, or even “forget about tests”. it’s just a very radical and extreme (for me, at any rate) reflection on the focus we give to quality. For one, i groove on quality while at the same time i can secretly admire that *some* manage to manage buggy software better than they can actually write it 
Bitnami Application Stacks
22.12.07Filed Under: technology with 0 Comments
If you’re looking for an application stack to run on *any* OS, particularly one of the very famous and useful open source applications (subversion, wordpress, joomla, drupal, apache, ruby, moodle, mysql, php, trac, …) and want to get started quickly, i would suggest bitnami for most your needs.
And especially if you’re stuck with a Windows server :p but really need to set something useful (server application) up and running, chances are, bitnami will have a stack you can download, click and install. They even have got Ruby on Rails. And the growth in the last few weeks has been quite considerable (ito offerings) so there’s very little excuse for not trying out (self-hosting) any of these wicked-cool apps on your internal networks
Enforcing DDD
08.12.07Filed Under: DDD, agile, programming with 0 Comments
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
Overdone
22.11.07Filed Under: opinion, programming with 0 Comments
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
TDD, Functions and Design
20.10.07Filed Under: programming with 0 Comments
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…
