Category: Business

Categories
Business Rants Technology

PAYE

UPDATE: 3 July 2008
Updated code to reflect more recent tax tables (2009)

When I was asked to estimate PAYE on a gross monthly salary, i hauled out the calculator and started chipping away, according to the SARS Tax Tables. Not being a tax consultant or looking at various structured packages, the first stab is mostly always a straightforward estimate without investigating further deductions. While doing this, the math-programmer inside me went… “Mmmm. Calculator. Boring. Ruby. Smile”

Turns out, it’s a simple little script; a useful little snippet and, bonus, i migrated some more learning onto Ruby. An aside; there’s definitely something about the difference in speed and endurance of learning between my brain versus my hands. You know the feeling. You can forget a password mentally, but let your fingers do the talking… And utilising muscle memory as an aid is just one of the many senses you can draw on…

Back to the snippet. Not too much interesting going on in terms of code. I chose a multidimensional array for storing the tax table. First used a hash, found it was overkill, reverted. Also did a classic switch in the beginning, to determine which “bracket” your pay falls into, but then figured a straightforward loop works just as well. This was an interesting break in habits from C# however.

In C#, looping through an array would be: for(int ii=0;ii<array.length-1;ii++)
I did the same in Ruby, transliterated the code, first time round: for ii in 0..array.length-1
But then, the knowledge of the “times” method changed my thinking completely: 6.times { |ii| … }
There are, afterall, one of 6 tax brackets you are likely to fall in (for all positive salaries)

And that’s where it hit me: the uncomfortable (more about that later) shift away from a corporate-sponsored, statically typed, IDE-integrated, certificate-oriented, compilable(?) programming language into a community-driven, dynamic scripting language is underpinned by these sudden ferocious rushes of freedom. Too much freedom? Certainly, too much to what i’m accustomed to sometimes.

Why’s that uncomfortable? Well, MSDN, VS, MS communities and the framework tell you how to code- to a large extent. They dictate the patterns, the constructs, the idioms; in short, they impose a very definite way of doing things. And it’s a big abstraction layer, forever changing (but not really) and giving you tons of resources to make your coding easier. This is good. Books, online help, built-in help, IDEs, intellisense… and more of all the good stuff. Don’t get me wrong, these things made me very productive and i’m grateful for that. But then you break away from that.

You gotta search for help (no nicely packaged MSDN DVD delivered to your door). You gotta scratch under the hood. You have to engage with community blogs and real people in a virtual world. You are forced to read opinions. You are stripped to the only the most simple of tools- a plain text editor. On a coding level, you are forced to remember namespaces, method names, variable names, libraries… no more intellisense to rely on. And this is where it was difficult. No more crutches to help me be more productive. I had to start thinking- for real now- and remembering stuff. And then i got scared: what if the “community” changed something and i didn’t know about it- or worse, didn’t agree with it? And I didn’t get an email with an updated change delivered to me automatically via updates or DVD? Hang on! Is that really the way it’s supposed to be? Have i become that lazy? Oops.

And all i was doing was having some fun, writing a little script to calculate PAYE so that next time someone asks me, i save myself a little more time.

Btw, the Source Code is here, if you’re interested.

Categories
Business Technology

Ding

That’s roughly equivalent to the sound of the resonating chord which struck me this morning.

But today’s revolutionaries are sheep in wolves’ clothing. They’re lost in the economically meaningless, in the utterly trivial, in the strategically banal: mostly, they’re cutting deals with one another to…try and sell more ads. That is, when they’re not too busy partying.

Oh, if it weren’t so true. The rest of the article, is soul-searching and uncomfortably challenging because it has that “truth bites” edge to it. It’s also filled with quotable quotes, not for the purpose of quoting, but for serving as reminders when you get enough chance to breathe and realize exactly what it is you are doing.

That is to say, it serves, at the bare minimum, as a reality control against going too far in one direction; but only if it failed to catalyze something deeper within you.

Categories
Business Technology

Investing in the Learning Curve

We have a concept of what the learning curve represents, and unfortunately, the same thing can represent 2 opposite concepts. What makes more sense to me is looking at a learning curve from a classical labour cost perspective and more keenly towards labour productivity. In this sense, the learning curve is interpreted, broadly, as: the more you work with something, the more productive (cheaper, better, faster, more knowledgeable) you become. And one can recognise that sentiment when it’s expressed variously with respect to success, specialization, expertise, productivity, quality or minimizing costs. So where’s the investment?

Programming technology changes rapidly, and sometimes to the detriment of programming and business, sometimes not, but also to the advantage of progress and for the sake of technology itself. But changes are also forced to be incremental in order to be successfully adopted, since any radical departure will result in a prohibitively expensive learning curve where the economic costs outweigh the advantages of the change. Similarly, you also cannot force change too frequently, even if it’s small enough, since you never get to break even or realise a profit from the previous change. I think this last point might also be reflected in the current developer attitudes towards the “next big Microsoft thing” and the ubiquitous jading of old hats. Everyone seems to hanging five for a bit before moving forward. Or maybe Douglas Adam’s theory is kicking in?

At the same time though, you need to keep moving forward. So where do you invest your next generation of development so as to minimize the costs of the learning curve if you want to remain marketable and competitive across:
* web development
* mobile application development
* backend systems
* any platform (platform agnostic)

C++, C, C#, VB, Perl, PHP, Python, Ruby… ?

All these languages have their pro’s and con’s and more importantly, costs. As an example, I recently looked at Symbian C++ development, and the learning curve is relatively expensive. The idioms alone take time to get to grips with, so although you got a very powerful API, C++ on Windows desktop, or legacy ATL knowledge is not easily transferrable to a Symbian C++ development effort. Possible, but no as easy as say, being able to use a standard framework and language, with the same idioms, on both (all) platforms. That would be the ultimate prize (for me).

And it doesn’t have to be the same language. Case in point, i’m currently using Monorail (.NET web development) and RoR (other web development) concurrently on different projects and i’m enjoying the benefit of being able to work in a predictable (hence productive) manner switching between the two, relatively seamlessly. Whereas, switching between asp.net webform development and RoR, as an example would not be feasible. The traditional 30% context switch overhead would double.

So if you’re faced with “what to learn next”, take a closer look at the learning curve and where you can (need to) apply that knowledge in the future, in order to remain competitive- whether globally, or within your own department. Maybe it’s stating the obvious, but it’s surprising just how un-obvious the obvious can become when there are a lot of flashing lights going off all the time. So it’s not always about the language or the technology, but also a lot about the “way” in which things are done; which, by nature, is usually a little more sublime to spot since it’s hiding in plain sight 😉

Categories
Business Technology

IT vs Business

Who’s gonna win?

Judging from the insights that are developing, not only within myself, but also from more prominent journalism, i would say business will eventually catch onto how IT’s supposed to be managed and augmented into adding value to the core focus of the business. Obviously, IT-centric business will be oh so slightly different. But the point is, if you’re a developer (as an example), you should be thinking of how to join the company, not the development team. Your approach and your skill-set should be centered on supporting the core business and not just how good you are at coding. This is a marked difference, and while some have been getting it right, it won’t take long before everyone is forced to get it right. Again, IT-centric (or technologically oriented) organisations will have their subtle differences.

What does that mean in the short term? Don’t think of business as ‘them’. It’s ‘us’. And there’s also no ‘us’ when it comes to the dev team. The ‘us’ is the company.

How do you identify with the change? Well, think of the any other division within your organisation. Accounts, procurement, call-center; any of them, all of them, see themselves as the business or aiding the business directly. They don’t have this distinction (by and large) of ‘there’s us’ and then ‘there’s the business’. It’s the same thing.

Getting this mindshift entrenched as part and parcel of IT as being within the company and not external to the company will certainly be a much needed move forward. The technological advances (again, programming wise) are not that radical; the improvements do need to come from another aspect, and this change looks to be it.

Categories
Business Rants Technology

IT “Industry”

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 😉

Categories
Business Rants Technology

Crack My App

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 🙂

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
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
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 😉