The power of the team

As mentioned in my last post among my roles I am, at present, primarily the main developer of the C# client application. I also mentioned that I was transferring to C# and that aside of some small projects in the past, this is my largest and most involved project in the technology.

The problem is that often I am the only developer on this project.

What does that mean? Well  can be a bit more blasé about making minor code changes directly on the trunk/main branch (version number increments and the like), but it also means that when I hit an issue I have nobody to discuss this with. This causes an additional delay in finding an appropriate solution.

Whilst the value of teamwork has always been obvious to me, this situation has bought it home to me on a couple of occasions. Two heads really are better than one.

With others working on a team I often find ideas and experience sharing multiply (at least up to a point). I'm not talking about pair programming (of which I have had only good experiences), but the fact that individuals will have different experience and approaches, and in some situations this proves to be invaluable.

Of course we all need to know how to work on our own (sometimes for extended periods of time, or entire projects), but having others to hand to bounce ideas off and suggest solutions is, I feel invaluable.

Naturally the effectiveness of this depends heavily on the nature of those involved. Those involved in software development are often not the most gregarious or social of people, however even those bordering on extreme autism (as I sometimes encounter in this industry) can turn out to be valuable colleges with the right approach.

Of course, there are also occasions where individuals are just plain obstructive, I just hope these people are quickly identified and moved on to more suitable roles (such as standing in line at the job center).

One other key skill I observed in my very first boss (whom I learned much from that I still use to this day) is not being to proud to learn from those with less experience than yourself. To paraphrase what I remember him once saying to me; "If you suggest fifty things which are just plain wrong, and only one thing that I had never occurred to me, then I'm better off because I have learnt something from you."

Crucially, he also had fifty opportunities to educate me in some way, which certainly happened.

Working alone is great, and sometimes required of desired, but even when this is the case having a team to fall back on is, I feel, invaluable. Nobody knows everything, but most people know something worthwhile... sooner or later.

Changing times

Since joining my current company two years ago I have been on a single project, transferring from a Java server development role to a position that also sees me as the main C# client developer, a situation that I actively pursued. This has helped keep my interest in the project alive(we developers are a fickle bunch who get easily bored) and allowed me to extend and expand my experience practically at the same time.

During this period the project has seen an initial major delivery and a second large delivery, but along with my mutating responsibilities the composition and size of the team has also varied during this period. As the bulk of the development work has been delivered the team has shrunk in size in all areas, development, test and management resources have come and gone, but mostly gone.

The time spent here has given me an opportunity to work with some good people, in terms of both talent and personality. Several of the people I've had the pleasure of working with have made my job better and more enjoyable than it may have otherwise been, and I'm pleased to say that comes from people both above and equal to me, as well as those with more and less experience than myself.

One of the things I have noticed is how specialised our current roles make us over time, and I believe this is something that is getting more pronounced as the breadth of technologies and libraries expand. That's not really news, it's something I've noticed before, along with probably virtually all others in this profession I would imagine. It should have come to be expected to a certain degree.

By specialised I mean that depending on what our current task has involved, or more specifically involves on a regular basis, each of us inadvertently becomes more knowledgeable in those particular areas than those we visit infrequently, we become a domain expert. Again, this is only to be expected, by my point is just how pronounced this knowledge unbalance now appears compared to how I viewed this in the past.

Years ago I knew people (and was hopefully one myself) who were competent in vast areas of a language or libraries, but specialised in a subset of those. Now it appears (at least to me) that the programming domain has grown to such an extent that we are becoming increasingly ignorant of areas in which we have no recent experience. The difference here is that where we once may have "known a little", we now know "a very little or nothing at all".

This is to be expected as the technology expands, but I feel it reveals an underlying problem in recruitment going forward, both in my future roles as an interviewer and an interviewee.

I suspect everyone who has looked for a job in development will have seen plenty of jobs requiring experience in just about everything going in a particular technology, most of which we will be aware of to a certain degree; some we will know inside out, others we've not visited for some time will be "rusty", and the final few we've never knowingly encountered.

As time goes by and technology expands this category of inexperience continues to expand rather than shrink. But here's the thing - if it's expanding for me with over twenty years experience, how are people with just a couple of years able to claim knowledge in these areas?

That's quite simple, just by having a basic understanding. I can probably tell you enough about rewiring a house to make you think I would be able to do it. If I actually did then re-wire the house, you'd probably find you got through a lot of fuses (possibly also a few calls to the fire brigade).

The same is true for the people claiming experience in multiple unrelated categories. I may be able to read an article or overview on a new technology/library/methodology, and this will be enough to get me through that section in an interview, but should I then need to use that skill I'd be starting from scratch - the exact same position as somebody who claimed to know nothing.

This raises two issues itself. 1. How can the interviewer tell how much you actually know from the interview (or indeed experience to a certain degree), but more importantly 2. How much does that actually matter?

The more important thing is to find somebody who has a core competence and who is willing to embrace new concepts, anything else can be learnt. We do it all the time, it's regularly part of the job. The trouble is if we're not learning the right things to tick off the right boxes we appear less skilled.

I'd argue that it is often those who don't appear to know a little about everything who know the most. Good luck making the distinction in one or two hour long segments which need to cover other areas though.

As time goes by I become more aware that many of the most consistently competent developers I've worked with have been focusing on a few key areas. They turn out consistently good code, and most importantly can actually be relied on to deliver.

In contrast I've also worked with a number of developers who have latched onto a wide array of technologies, who would be able to suggest any number of new tools appropriate to deliver a particular solution, but who ultimately turn out code that barely works, is poorly constructed and is over complicated (by either use of too many technologies, patterns, or just generally over engineered). And that's is they manage to deliver anything at all.

The trouble is who is going to look better in the interview?

Seeing through this is an art that is not necessarily possible in a series of interviews, you sometimes just have to go with gut instinct, but one thing that is worth considering is this: A good developer will be able to learn a new skill and apply it to get results as required. A "less capable" developer may know everything about everything, but if they can't deliver on that...

Unfortunately looking at job advertisements it seems this latter class is expanding quickly and being sought more highly.

Perhaps that's why the architecture is now a separate beast to development, they have to go somewhere when they're found out.

I wonder how this will pan out...

Well, I don't think Microsoft will be loosing much sleep over it, but it appears that two unrelated situations mean I'm going to start looking into developing Android applications rather than for Windows Phone, at least in the short term, allow me to explain:

The first culprits involve the decisions Microsoft are taking with the direction of Windows Phone 7. It started off with the removal (or is it actually more accurate to say omission?) of Cut and Paste functionality. From articles I've been reading recently this is down to a lack of time for getting it developed by release time, rather than not knowing how to implement it. As a friend from Nokia commented "What, were they worried they could do cut and not paste in the time available?".

The lack of C&P was originally sold to developers as a conscious decision ("A phone doesn't need C&P" - Really? Then why write Office Tools for it?), now we're told "it's coming later". Not the end of the world, but frustrating. Still, I agree it's better to get it right than put in something that's buggy or badly designed and then be stuck with it forever more.

The killer move, for me, is the apparent lack of any way of side-loading applications. As is the case with iOS, you get your applications from Windows Marketplace or not at all. That's essentially shut me out. It's all very well running anything I code in a desktop emulator, but then I may as well have just written a desktop application. If I can't actually get it onto a phone (and possibly those of my friends) what's the point? This is the number one reason why I've avoided Apple phones all this time.

Then there is the work related chain of events.

When I started out at my previous job the plan was to move into C# (as I believed the role required, it's certainly what was advertised and what I interviewed for). Previously I had been working in Java but I was happy to move to C#, it's a great langusge. Being a Java developer a large personal application I had been working on I was also written in Java. When I "moved" to C# I started porting my code over too. Doing such things works as a good aid in getting to grips with a new language or language features.

Now I'm going back the other way to Java as the primary language in my work role, so guess what else I'm now planning on doing? [Moving my application back to Java]

Here's the killer: Just as I was hoping the C# code would allow me to share core components of the application between Windows, Windows Mobile and Phone, and possibly web sites, it turns out that the primary development language for Android appears to be Java.

So now Java potentially gives me access to Android Phones, The Android OS (for Laptops, Slates, etc.), and with a little work (hopefully not too much) Windows, Linux, MacOS, possibly even MeeGo. Oh, and I believe web servers can also run something called servlets too. Oh, and just for fun, the Windows Mobile phone I currently have includes Java too... oh, and I know S60 used to run Java. Wow!

The killer which I'm brushing over is obviously that there will be an incredible amount of work to customise the user experience and display for each system, possibly this could be the lions share of the work, but I do at least take some comfort that at least some of the core business logic may be sharable between systems.

Looks like until my priorities change again this is the logical route for me to get back into Java in my spare time above the demands of work.

So now the new laptop has arrived one of the first things going onto it will be a shiny new install of Eclipse and the Android SDK. Oh, did I mention that's all free? That's possibly a little unfair a comparison, the Express versions of Visual Studio are excellent (that's one of the downsides to all this, I find the Visual Studio IDE an absolute joy to use. For Java development I prefer NetBeans, but since I'm on Eclipse at work, and most of the Android documentation references Eclipse I may as well use that).

Will you ever see any of these fruits of my labour? probably not (almost certainly not), but the point is the more I play, the more I learn, and as long as some of that is relevant I end up getting something out of it over and above the hobby side.

Now, of course, I'm reliant on Oracle not screwing things up with Java (well, no more than Sun managed at the very least).

Fingers crossed.

Testing Times

Looks like this is going to be one of those rare blog entries that will live in both my tech and personal blog since I don't know where to put it. I guess that's good. Anyway:

Well, it's week number four in my new job. i have a desk, a machine and I'm just about set up with my development environment. There's a few things I've not been briefed on or covered yet, some of them quite basic (like how about giving me a Jira account, that may be useful soon, or on what branch do these guys do all their development, surely not main_latest all the time?!!)

So what have I achieved so far?

Well, not a lot yet, and it's starting to bother me. I've so far been given a single 2 part task with the aim of speeding up the build tests:

• Go through a bunch of JUnit tests and remove anything not testing actual business logic (so for exampe if its a persist or retrieve operation, take it out).
• Investigate getting the JUnit tests to run in parallel.

That's not so bad for a first task on an unfamiliar system.

So I spent just under a day looking at a select bunch of JUnit test code trying to decipher what was and wasn't a business logic test. Sounds quite easy, but since a lot of methods are masking non-business logic, it's very easy to leave them in. Similarly, what looks like a persist operation may be an actual calculation of one variety of another. Then you have the methods that call both responsibilities, or rely on persisted data to pass. It's not as easy as it first looked, especially on an application with which you are not familiar.

The upshot of all this? I came to the conclusion that there probably wasn't any business logic being tested in the set of tests I was looking at. I was, as you might imagine, uneasy with this deduction, it felt wrong and I couldn't be 100% sure my findings were correct, however when I returned to my "mentor" for this task he didn't seem to surprised and commented "I've skimmed over this myself and I didn't see anything leap out either."

Oh thanks.

Actually one thing that did amuse me, I had flagged up one test as possibly being business logic, however as my mentor was looking into this I noticed a section of code that clearly suggested otherwise, so at least I beat him to that one.

With that task out of the way I started looking at making the JUnit tests run in parallel. A little research on the web revealed what was needed (including a version of Spring that's still in RC status). Undeterred I created a small project with a bunch tests to try this stuff out, and sure enough it worked as I expected (albiet without a hint of Spring in sight, unlike the real project). So how did it go once I started applying this new found knowledge to actual project... well I've been on it a week now and I'll be sure to let you know what I find when I finish (if you ask nicely).

I've been hit by numerous issues with my development environment, and on the odd occasion when things do work as expected, a run can take up to 26 minutes (usually closer to 19 for a full run - at least for what I'm covering). The worst thing is I'm only making changes to a handful of POM.xml files and so far the results show no avantage at all. At this rate my findinge will be: "Hey, I've spent over a week and can't get any speed increase". That hardly makes me fell very good and I don't actually feel I've achieved anything yet. Especially when for the most part my day consists of the following routine:

1. Start machine. Spend 1 to 2 hours getting the build to work properly.
2. Make a small, well trodden modification to all 4 instances of a command in 3 pom files. (5 mins max, probably closer to 2 mins)
3. Fire off build and wait to complete (up to 19 minutes if it completes)
4. Investigate any errors or note timings (2 to 10 mins).
5. Repeat from step 2 until time to go to lunch or home.

I can't help feeling this should have been finished some time ago. I know deep-down proving something doesn't work is as important as proving it does, but this seems to be dragging now. it feels like my fault, but frankly i don't know how to make it better, it's just the nature of this particular beast.

I guess deep down I feel the need to prove myself as the new boy, and with this task I feel like I'm coming up short, rightly or wrongly. Oh well, I guess that could be me worrying too much. Sometimes, that's just the way it is.

It’s not me, I’m perfect!

I think I'm in a minority here, but the state of comments in some code is truly appalling, and the worst offenders are those who think their code is so clear or logical it doesn't need commenting.

I've worked with many such delusional characters over the years, and it always seems to be he ones who should know better, the "above average developers", and you can measure that however you feel.

The thing is, they are correct, or at least they would be if they were working on one-man projects. The code is clear to the author as it comes from their thought process. What's obvious to them is often far from obvious to everyone around them, and this state of affairs is made worse when using call-backs, events or making use of things such as multi-threading.

The argument is usually either "the code is self commenting" or "adding comments will confuse the code" and "comments become out of date quickly and therefore misleading". I'll briefly address these points now:

The code is self commenting.

Indeed, the code ideally should be, but how about a general overview of what happens? And is it really? The people who claim the code in such are often the authors of long, convoluted methods, with no clean responsibility, lots of inner classes or methods (depending on the language).

This code is difficult for others not familiar with it (often that equates to everyone other than the original author) to follow, but amusingly it is often tricky for the original author to understand when returning to code after some absence.

The times I've seen such developers struggle to understand what they were trying to achieve in a piece of code is frightening, but they normally get it fairly quickly as it comes from their imagination. If only everyone else was looking at it from the same perspective, then you may have a point.

Yes, the code can be self commenting, but to me this means well named methods with a clear responsibility, not a 40+ line method that covers all branches of execution.

Adding comments confuses or detracts from the code.

Well, it's often subjective, but I agree that adding too many comments does detract from the code and make it more difficult to understand. Having said that, a comment that briefly describes what a particular method is trying to achieve (something akin to JavaDoc or the .Net triple slashes if available) can be an immense aid to a tired developer trying to understand how something is supposed to work. This can occasionally even be a reference to the functional specification if you're lucky enough to have one. Such comments can be easily ignored if you find them offensive.

I'd also go so far at to say an occasional comment before a section of "non trivial" code can help both the initial development (I often use comments to help provide a skeleton and program into them) and future maintenance.

Comments become out of date quickly and therefore misleading

Then you're not treating them with the respect they deserve. Isn't that a bit like saying "it compiles so it will run?". Of course, tracing comments that need updating can be a chore, but if they are finely grained and focused on what is actually happening  in the particular concern they are attached to, code and comment modifications can be performed hand in hand. Anything else, go to the specification.

In my opinion you should target your comments at others not yourself (although having said that my memory is sufficiently poor that I will happily use my own comments as a reminder). Assume little and ensure you give a decent starting point for further investigation at the very least. And for the love of god comment any gotchas or what you did to avoid them. Often we add code that looks out of place or redundant just to get around such things (yes, I know there may be a design flaw, but we'll code with a view to make a refactor as soon as we can go more easily and actually get the product out of the door (and that's a whole other post).

I could go on with this post, but in a nutshell I'm just sick of trawling through thousands of lines of uncommented code that should make perfect sense, but are complex enough to only be apparent to the author, and even then the author often struggles.

Apple Rules!

I’m at once both loving and despairing over the spat between Apple and, primarily, Adobe.

In cutting off Adobe and other companies with their rules limiting of the source code requirements of applications (which as a developer strikes me as being quite strange) other tools apart from Flash have been affected. The nature of the development beat these days relies on a variety of tools to get applications delivered, not just a few chosen languages with massive do-it-all libraries.

Add to that the fact that Apple takes advantage of many closed APIs in the OS which other developers are expressly forbidden to utilise (for example the iBooks application uses closed APIs to do things as simple as adjust screen brightness, from what I’m lead to believe), and a lot of developers are getting… frustrated.

If the iPhone/iPad apps keep selling, then they’ll keep being developed, but as more and more competing operating systems rise through the ranks, the appeal will start to waver, developers who have been rejected or withdrawn from the App store will start to question where their time is better spent, and the flow of new apps may (just may) be directed to alternative devices.

Slowly the iPhone will be less appealing, sell fewer units, and the process will enter a cycle like Microsoft is now trying to get out of on their mobile platform (although this was for different reasons, mainly neglect of the OS at Microsoft).

I doubt there will be any measurable effect on Apple sales any time soon, it may not happen at all, but I suspect Apple may currently be sowing the seeds of its own destruction. That would actually be a bad thing as fewer players may lead to less innovation. Having said that, the mobile economy is so large at the moment that this is unlikely to happen any time soon.

Footnote: Don’t give me any rubbish about keeping the iPhone interface consistent over applications in the OS, have you seen iTunes on a PC? Even Sun introduced a Windows look and feel for Java.

Scrum

The guys over at AxoSoft, creators of the rather good OnTime software have produced a video Scrum in Under 10 Minutes as a quick introduction to Scrum.

Scrum is nothing earth shattering, and it’s not going to be a silver bullet for many people, but it’s well worth a look, and if followed correctly I’ve no doubt it will help a lot of projects run more smoothly.

Of course, the video is a gentle advert for the AxoSoft OnTime application, but it’s not forced at you so is worth a watch.

As it stands the company I work for has started using OnTime, but at the moment it’s just performing a to-do list and time logging role for me, and I suspect most of the other team. We’re yet to take the bull by the horns and make effective use of the many features.

Oh well, hopefully we’ll get there. Certainly on the task I’m working on at the moment a burn down chart (or even some smaller milestones) may have provided a morale boost that we are actually making progress.

Never mind.

Drawing to a new conclusion...

As those of you who read my various other web sites (and the earlier incarnation of this blog) may be aware, I started a new job at the end of April this year which resulted in me moving from a Java (and occasionally SQL) developer, on to C# (via Microsoft Visual Studio 2008) and back to (what has become over the years) the nightmare of Delphi 5.

Delphi, specifically version 5 was way ahead of the crowd in it's time, unfortunately that time was 1999. I used to love Delphi, it was so advanced compared to similar offerings such as Visual Basic that anyone who had used it seriously didn't want to go back to other languages unless they were offered a seriously large pay-cheque to do so.

Then a series of events happened which saw Delphi get left behind, the two main (from my perspective) being:

1. Java arrived and offered the opportunity to program in a new object oriented language that allowed code to run across different platforms. Many Delphi developers moved over to Java, and by using JBuilder which also originated at Borland, we felt at home in a familiar IDE too (versions 1 to 3 of JBuilder were written in Delphi, JBuilder 3.5 was the first native Java IDE for JBuilder).
2. Anders Hejlsberg was poached from Borland by Microsoft and as a result the lead architect had gone. Don't get me wrong, there were a lot of very talented people at Borland, but despite this there was always the perception (accurate or otherwise) that after Anders jumpred ship, the product was left in disarray.

Delphi was never as popular again.

This is all a long time before the .Net platform, and more importantly for the remaining Delphi developers, C# started shipping. In fact, Anders Hejlsberg was the chief architecht of C# after his J# language, understandably, upset Sun, so morphed into Cool, which was eventually released as C# (at least that's how I remember it).

Despite remaining a solid language, Delphi started to stagnate and fall behind Java and C# in terms of features and the integration of new technologies at that time. Although Delphi version 7 was a particularly good release (as far as I remember, was it version 4 that was always rubbish, even after two service packs?) it just wasn't enough. The job ads for Delphi were starting to decline, and its hey-day was now behind it. As a develper, that raises some concerns, and for me it was time to move on.

Java became my language of choice. Not only was the JDK free, but I'd been playing around with it since late 1996 in the version 1.0 builds. So it was that I moved to a job offering cross training to Java from Delphi, which after some complaining eventually happened.

And so Java started to pay the bills as well, if not better, than Delphi had in previous years. However apart from a few notable times (such as when James Talbot introduced me to the Spring Framework, thanks James) Java development was never as much fun as Delphi in those early days.

Don't get me wrong, I like Java a lot, but it rarely had the comparatively instant gratification moments that Delphi often provided. I think a lot of this can be down to two points: My Java programming involved little Swing (or indeed any visual) work, so whilst it was immensley satisfying to get JSP being constructed from a web server, or process huge amounts of financial data, it didn't grab my imagination in quite the same way. The second problem is that Java does so much I could never hope to be comfortable with it all. It is true that this is the case with Delphi (DCOM required me to grab a book and ISAPI extensions have never been produced by this particular mortal) and also C#, but with Java you always felt like you should know it all, it's not enough to just be aware it exists until you need to use it.

So now I'm spending a proprtion of my work time developing in C#, and to my great delight I find it has some of the same highlights as Delphi used to, only more applicable to the world of now. I don't wish to be unfair to the latest versions of Delphi, which I believe are very good, but the whole community around C# is massive, and it's not the dog of a language that Visual Basic was (is?)

I'm now re-learning how to implement things like threading in yet another language. I don't regret this for a moment though as not only may the approaches to some things have changed over the years, but I also believe that in doing this you always get a little deeper understanding, and hopefully wash away a few of the bad habits you may have picked up over the years.

One of the new areas I'm interested in investigating further is the Windows Presentation Framework (WPF or Avalon to some). This looks similar in many basic ways to Swing in Java, only it feels like a later revision. As a result hopefully I'll be able to take back some of what I learn to future Swing applications.

WPF is still quite new (having been released alongside Windows Vista) and the plan is eventually to make this and Silverlight one and the same thing (or so I believe, at the moment Silverlight uses a subset of WPF).

The down side on this is that a lot of the announcements about Silverlight 4 seem to be moving away from cross platform solutions towards Windows only technologies such as COM. I guess time will tell on that front.

WPF is also a core component of Windows 7, so there's significant opportunity there. Also, I believe, the Windows Mobile 7 UI will be rendered in WPF... that will be awesome if/when it happens. And if they start to add the tools into Visual Studio Express from installation then the uptake of WM7 will only improve in my opinion (you can code Windows Mobile Apps without Visual Studio, but it's a lot more complicated without Visual Studio Professional of above. See my later Windows 7 follow-up post in a few days for more of what I think about this).

There's lots of new things being offered by .Net and C# that I need to look into, if not become an expert in, but just to be aware and not completely ignorant of them. The way I'm approaching this is far more relaxed than Java, so hopefully it will be more fun and I'll achieve even more, then take some of the positives back to Java some time in the future.

At last I am once again excited about the possibilities. I just need to shed some (or all) of this Delphi work to give it more of the time it deserves. Oh well, needs must.