Forestry Management (Tree Health)

Premise: When you are deep within a great forest, trying to get to the other side, it is very easy to get lost amongst the trees. The leafy canopy, the dark moss on the ground, the hairy spiders attacking you.


Let me start this article by transporting your mind with a song. Picture your favourite musical, or that episode of the Simpson’s where Mr. Burns sings "See My Vest".

If you go down to the woods today,Be sure it is with a goalIf you code down in the woods today,You’d better get in control

For every time you push further in,And forget to take a moment outWell that’s the day that you project comes to eat you

Ahem. Again.

The idea (and title) for this article came directly from a conversation with Bill. I’m deep within a project at the moment, coding like a maniac, and realising (slowly), that it’s not good enough just to code. Just to port across the old code, or even transform the old code into new. That’s good, but only part of the picture.

Development, done properly, is really hard. Your brain has to not only be code orientated, but also global-direction orientated. And probably a few more directions as well. Definitely.

That is, when you are deep in the midst of coding a window with half a dozen different windows underneath it and some very complex logic to calculate certain values, calling a few more different procedures/functions, it is very hard to pull out and check the direction.

Let’s get serious. Most development is about creating a solution to a problem and/or need. There are a bunch of rules that drive the project that don’t have anything to do with the underlying code. That is, because we are the best at what we do (heh heh, Ego), we can get the code to assimilate whatever Rules are thrown at us.

This is good. But it’s easy to lose sight of those Rules. Especially in a complicated project.

So how do you do manage these two poles?

I think the answer is easy to realise, but much harder to implement.

It requires great discipline of mind. Well, to start with. Then, hopefully, like some, it will become almost second nature. To be able to split your mind and make sure that as you are thinking through the coding functionality, and even the low-level Rule functionality, that you are maintaining a grasp on the high-leve Rules.

There is more to this. It’s not just about thought processes. You have to do the unthinkable, stop coding, and test the sucker.

This applies to the developer doing a project on their own, and the developer who is part of a fifty-man team working on the next Duke Nukem, Hail to the King Baby! (Sidenote : What’s going on with this? I want to shoot pig peeps!). Every project you develop, or part thereof, is your own little kingdom, even if for only a moment. Make it your own.

Testing. It’s like drinking coke after years of diet coke abuse. Urggg.

But it has to be done. And you gotta change your palate to accomodate and make it part of your total development package. If you follow case-studies, or something similar, and add real data to your project as you code it, then you will come out the other end not only with a far more polished product, but also a better developer. Because you will pick things up, and evolve your development brain.

We have to grow our development brains. They are what is going from project to project. Own the project, for sure, but it’s gonna go. Until we leave this mortal coil, and probably a little before then when the mental faculties start to break down, our development brains are what gives us our vocation. So feed them, nourish them, work them.

As always, writing this article has uncovered other things. I wanted to talk about not losing track of the Rules of the project when in DeepCode, and discovered a further Dev Dawn purpose. Or rather, a development in the purpose of Dev Dawn.

The Development Brain.

More later. Thanks for showing up.

How Do You Solve Problems?

The Problem Solving ability. Some people are born with it. Others, like myself, learn it over time. For me, it’s a never-ending quest.

When faced with a problem, which might be big or small, it is the ability to break this problem down to the base elements, and then address them.

One of the disciplines needed when solving problems, is that of ‘Test Everything’. Don’t believe what people tell you. Listen, then work it out for yourself. Just because people say it, doesn’t mean that’s the case.

I’m prone to just believing. It’s easier, and you "get along" better when you just nod your head. I do it WAY too much. Sometimes it’s appropriate, when it’s better to actually forge a relationship than the other. BUT … when solving a problem, and I’m specifically thinking about this in terms of a group of people sitting around a table trying to nut out an issue, the Test Before Belief approach is far better for actually getting to the heart of the problem.

Imagine a company who’s IT department has gone through a number of management phases, each of which add their own little unique segments to whatever hardware/software runs the company. Most of the time, these aren’t actually documented. Nothing is ever done about planning the architecture, and if any planning occurs, it’s usually short-sighted.

Then everything goes down … because there is no disparate architecture, the diagnostics are up the creek. How do we tell what element is screwing up when everything is lumped together? It’s a common problem no doubt, and to a greater or smaller extent, everyone in IT will come across in their lifetime.

So how do you approach the problem? Jump in, lightsaber flashing, beating down any and every-thing in an attempt to fix the issue … this might have a certain attraction, especially considering that you will get a reaction. But it doesn’t actually solve the problem. If you restart the servers, the problem might go away for ten minutes, only to regroup and return with greater force than before (excuse the war analogy :)).

The best approach I’ve seen, working with some great minds, is that of the Listen,Test Before Belief, and Break Down To Basics.

  1. Listen to what the people who deal with the problem are saying. If it’s yourself, clean up your thoughts, write down something, get it ordered.

    While you’re listening, think about what is being said (or not said) behind their words. And think about the problem … are they actually addressing it? Maybe … maybe not.

    If they’re missing the point, guide them towards it. Ask another question, more pointed towards the actual reason. The questions you ask can be as important as finding the problem. With well-formed questions, you can diagnose the problem with much greater efficiency, and others learn in the process.

  2. Don’t believe something just because someone says it.

    It doesn’t matter if the person talking has the smartest brain in the history of humanity, test before belief. It’s not a personal affront to someone’s ego, although it will be taken that way. It’s the ability to see beyond. That if you make assumptions based on people’s words, then you miss the point. The most efficient way is straight.

    There are a lot of things happening when people talk. A lot of different emphases placed on their words. Different aspects directing their talk. If I’m worried about my job, then that will become part of the conversation. I’ll be defensive and make sure what I say covers my behind. I’ve fallen into this many times. You’re worried because you feel that you haven’t been accomplishing as much as you could, and so it’s the first thing that jumps into your mind when someone is talking to you.

    It could be any other reason. Bias is just a part of life … we have to deal with it.

    It took me a long time to deal with, and I still haven’t got it right. On the receiving and the dealing sides.

    So … the third.

  3. Breaking down to basics.

    This is where we end up. Instead of getting caught up in the small issues, instead of jumping in without thought, instead of starting a row by treading on someone’s feet while telling them it doesn’t hurt … you get to the heart of the issue. Which can be a few things.

    Break the problem down. How? By asking the right questions, by thinking as they talk, by listening to the answers, the said and unsaid. Don’t get offended if you are the person giving the answer and you get shot down a little … turn your mind to the problem, and break it down yourself.

    Why is it happening? How can I verify that it’s happening. Which part of the system is giving the problem? Hardware/Software/Both? Can I replicate on demand the issue.

    This last is important. If you get into a corner, where nothing seems to work, then create a clean testbed and make the problem happen.

    It all leads to being able to break the problem down into basics, and then deal with them each.

    Much easier.

And there are great side-effects from tackling problems this way. You actually gain direction. Working through a problem also works other things out in your mind. You might come out with the next 6 months planned, and with future ideas. You will want to put into place methods/systems to ensure this doesn’t happen again, and if it does, your diagnostics will be equal to the task.

It’s such an important part of Development (and every other facet of life).

Listen, Test Before Belief, and Break Down To Basics.

Thaks for the time.

How Do You Stay Motivated?

Development times can be long. You might have been developing a system for months, or a year, or many years.

Specifically, I was thinking about the initial stage of development, before a launch. After launch, well … it’s a long road, bugs, new functionality, user complaints … etc.

But for the Initial Stage you are alone pretty much, especially before any kind of alpha testing happens. It’s you (team/individual) and your code.

  1. This is a good thing.You control the destiny of the project. You have the blueprint, the direction, no matter how developed that plan is. You can push further, put together systems, management tools, methods of practice.

    Breaking down the project is a must. To achieve smaller blocks of code/functionality/development will be far better than just approaching the whole entire blob and "just do it".

    So how do you break things down? From my experience, spending a little time with this is going to bring dividends almost instantly, and onwards. It’s possible to chop up a project into functionality breakpoints. This is probably the most likely way to go. In fact, it’s how my current project is done.

    However, I’m beginning to wonder if we shouldn’t approach things from a slightly different perspective. I haven’t got any concrete ideas here yet, just some possibilities. Anyway …

    How do you split up a project functionality wise? Mostly chronological. But then, if you’re developing from scratch, how do you plan for functionality that isn’t known yet, but will be discovered along the way? Problems that will arise by going down a certain database design track? Methods that will break other methods in the future?

    I haven’t been in the business long, but so far, I haven’t found a super answer. Just a little one. Make sure that things are done simply. If I can understand the project simply, then break down that into more little simple parts, then things move easier.

    That’s not to say problems won’t occur. They will. But so far, I’ve found that the harder you work at making code/structures/development simple, the better equipped you are to deal with any issues along the way.

  2. This is a bad thingEspecially for a project that takes more than six months (and you are a small team, or individual), how do you maintain enthusiasm through this time? After a while, even the small breakpoints can lose their lustre. Weekly meetings can be bluffed, although I’m not sure about daily meetings. That would probably help. The Scrummaging methodology comes to mind here.

    But then, that wouldn’t be enough. If you don’t have motivation, then productivity will fall.

    The first Motivation (big ‘M’) that comes to mind is that of job security. It’s the big one I guess, for most people. [ Marge: The plant called and said if you don’t come in tomorrow, don’t bother coming in Monday. ] Homer: "WOOHOO! 4 day weekend!". Well, that’s a Simpsons quote, but you get the point.

    However, I don’t think that it should be very important. It can be a motivation, but it’s not going to solve the heart of the problem.

    The "heart" of the problem? It’s a few things. Job satisfaction. The ability to develop relationships. Physical health. The ability to grow relationships. Mental health. The ability to foster relationships.


    Now, I know that this might be a problem for people. After all, there is noone perfect. And that’s right, there isn’t. There are plenty of people working, developing, coding etc, who aren’t in physical/mental health, and who aren’t good at relationships. That’s the way it is. None of us are perfect at any of these things.

    But that’s not the point. In this specific instance, a development team, I believe that developing a healthy relationship amongst the team is the first key element to a strong development team. It continues through everything, because it won’t happen overnight, and probably not for many months. But it’s vital. I want to work with a team where I can be able to trust the people I’m working with. Where I know the manager is looking out for my interests, as well as that of the team. Where we can know that everyone’s ideas are valued, and where we can be chastised with some form of graciousness.

    So my thinking is that the first Motivation is that of relationships.

    This is true if you work alone too. I began my Dev life on my own, for a few years. It was through forums, emails, phonecalls, and just talking to people.

Of course, this is all conjecture. I have yet to reach ten years in Development, I’ve no problem being labelled a newb.

It’s important for us to think about these things, because if I get to the end of my life, and can remember relationships rather than how much money I made, then I’ll be happy.

This isn’t discounting the practical methods of maintaining enthusiasm, and of project management, etc etc. It’s just looking at one particularly important aspect. One which, as above said, I think is vital. Foundational.

Thanks for stopping by.

Tiers of Development


I was going to name this article "Stages" of Development, but one of the main points is that they are tiers. Not everyone gets past the first tier. I guess instead of stages I wanted to give the impression of height (tiers), rather than a road (stages). Although, the road is a good analogy. Because development is a road.

So I’ve screwed my own article before beginning. Ha.

You can substitute Stages or Levels or any kind of describing word that measures stepping points in wherever you see "Tiers" in this article.

To begin. In this article I have put down four tiers. Each of the four can most definately be broken up into more, especially the third. But to keep them concise, four will do.

When we look at development, how do we approach it? When working on a project, where do you come in? At the beginning, or at the end? How much of the project do you get to be a part of? Development has such a far-reaching area of influence.

This is biased more towards the small developer (development house) who’s livelyhood depends on each and every one of these tiers, but working in larger groups you would still come across at least the first tier.

  1. The Functionality

    This is where most people start. The idea breaks upon your mind like the new dawn. It is such a massively ground-breaking, earth-shattering concept that even Google themselves would quiver at your feet.

    It’s also the place where most people get bogged in.

    "I’ve got this awesome idea for a piece of software / hardware / tech-savvy-functionality"

    Joel of Software states:

    I’m convinced that most people think about software companies in an upside-down way. The common belief is that when you’re building a software company, the goal is to find a neat idea that solves some problem which hasn’t been solved before, implement it, and make a fortune. We’ll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works. If you understand this, it’s easier to make the right strategic decisions.

    The key is to understand what makes money, what the need is, and convert that into software. Being strategic often requires dumping the craziest newest funnest idea for something a little more mundane to begin with. I can’t count the number of awesome ideas I’ve had that have been (after some groaning on my part) archived for use when I’m using 100 dollar bills for tissues.

    It’s more important to build an environment where Development can be fostered and grown than just coming up with a great idea and throwing a few workers at the "idea".

  2. Support

    "How do I support this Project?" re: the Customer/Client

    When you get to this stage, it’s a big change. Gone are the days/nights of coding for ten hours straight. Well, you’ll most likely be having to do them AND develop a system of Support. This is not just putting together a bit of software to manage phonecalls. We’re talking about strategy again.

    How can you let the Customer/Client know that they are valuable? And that you are actually taking their concern seriously?

    Then, how can you get the Customer/Client to voluntarily give praise? That is, not just on a Support Call well done, but just because everything about their dealings with you gives them joy, and they tell others about you.

    The initial software query is important though. It greases up the scotsman, so to speak. The better your software, the more you can do for your Customer/Client because you are freed up from debugging why the Support Team’s phone logs are tallying wrong.

    Another important point here is that of compartments. Working in a small development environment, I’ve seen that it’s very easy for the programmer, if they know enough about the System you’re supporting, to become a Level 3 Support person. They’re getting flack for not fixing bugs, while having to answer the hard support calls, while struggling to maintain any kind of job satisfaction because what they’re doing basically … sucks.

    This is easier to manage (I would imagine) in a large company where your resources are more concrete and distinct. The trouble in a smaller arena is that sometimes it cannot be helped. So the key then is to manage everything.

    We are getting into other areas here too! When you believe in the importance of a community when developing, then burnout becomes something to address. Job satisfaction is so very important. Especially for the guru who’s been with the company for twenty years, since the program was dos single entry old-school. But that’s for another article, another day, in another dimension perhaps.

  3. Marketing, Demonstrating

    This is where the rubber hits that black road of business. You get this right, and BAM … guru status. Client’s are willing to pay you good money for your product. You get it wrong, and BOOM … bad press and word of mouth will kill your chances of success.

    This tier is very hard to get right because it’s so far removed from coding and putting together functionality. It’s a different beast altogether. Going up in front of thirty hard-headed company execs will require becoming something else entirely.

    You have to become fluent at public speaking, you need to be an engaging speaker, and someone who will get to the point without offence. You have perhaps a few spare moments to convince the person/people that what you have is better than what they have, and anything else that is out there. You will give them something unique, your product will help them in some unique way.

    In my first experiences with this, on my own, I had a Freight System (logistics, Truck companies mostly) which was pretty good. Of course, that pov was coming from having not much idea at all about the competition, and having two clients. Count em. One, Two. I went through the yellowpages online, put together a quick client system that held their details, how many times I’d contacted them, how I contact them, and then got to work.

    One hundred flyers (and a letter) went out. I began making phonecalls three days after. Here’s the breakdown.

    1. One person rang me off their own steam.

    2. Of the other ninety-nine I could actually contact, Zero were interested.

    Now, 1. was an interesting experience. I travelled a couple of hours to speak with the potential client. He was a gruff, loud and cranky fellow, as are most truck-drivers turned business-men, because they have to be to get anywhere. After telling me about the last software guy who screwed him over (and who he pulled his shotgun on), I was pretty much a wreck. I had no real experience, and no real confidence.

    Confidence is what makes or breaks the marketing and demo-ing. You must make the people believe in what you have. My problem was that I knew all the problems with the software, how much it couldn’t do.

    2. is easy to break down. I learnt a lot about phone manner. Most people could be convinced at least to have me come and give them a demonstration. But because of my (as above mentioned) inherent confidence issues, I let them off way to easily. Persistence is important. Not being annoying, but persistent.

  4. Sales, Advertising

    This tier joins with the previous one a lot. The purpose of tier three is to make the potential Customer/Client believe in what you have.

    This tier is about getting over the line. And then pushing to the next one.

    Having a robust sales strategy (business plan) is vital. Whether it’s a monthly fee, or one-off, or yearly … whatever, make sure you’ve nutted it out. Show it to people, send it to the people in the know.

    Licencing is part and parcel with developing software today. You should not sell your software, but a licence to it. There is also a need to teach (graciously) the Customer/Client of the truth that just because you have a product now, doesn’t mean you aren’t going to conitnue to work on it. A one off fee might sound okay, but getting a monthly fee seems smarter to me. After all, you don’t just stop working after you’ve sold the product. Coding still goes ahead, as does Support. There are exceptions to this, no doubt. But generally speaking, it’s the way to go.

As I finish this article, it’s become more real to me that even four tiers is too simple. There is so much that could be written about development. But hopefully you have had an enjoyable read. Maybe disagreed (and commented your disagreements). Maybe laughed. Maybe cheered wildly and proclaimed Dev Dawn to be the Pinnacle of Truth. Maybe.

Puffed yet? This was a mammoth effort, particularly because most of it came off the bat.

But thankyou for reading. It is much appreciated.

The Cycling Santa

At our local Shopping Centre they put up this little Santa dude on a tiny bicycle that travels between two pillars. One end of the wire is fixed, the other on a circular rotation. He just goes back and forwards, back and forwards. So very simple.

Simple. My kids absolutely love it. I mean, every time we pass it they want to stand and watch.


And it got me thinking today, as we passed by underneath the jolly fellow.

The construction of the cycling santa is pretty simple. It relies on a lot of outside functionality. Gravity, momentum … physics. These are the building blocks that were already in place. They were the development suite , the 4gl language. All the developer did was put together a pretty UI and a very simple engine.

And it holds the attention of my kids (and me included) long enough for a handy pickpocket to do the rounds. Well … that was a side-thought :) … but anyway. It grabs the attention.

And that is enough. You get the people in. Then, once they’re watching Santa, you need a plan for what comes next.

But that’s for a later post. When my brain thinks it through a bit more. The point of this is that simple systems wrapped around constructs (the physics and absolute truths of our own development worlds) that are already part and parcel with what we do, is a very smart way to develop.

We need to think about what things just are in our world. The Internet, in all it’s forms. Conduits of information. And the Interfaces to that information.

Nice. That’s a succinct little detour-ee thought.

Break down what we do. Conduits of Information. Interfaces to that Information.


Anyway, yeah. The Cycling Santa. He reminds me to work very hard at making complex things simple. At using the building blocks that are already in existance. He says to use the simple functionality to draw people in.

Thanks for listening, this has been another Dev Dawn broadcast.

Colossal Ego vs Self-Awareness

If there is one sure thing in the world of development, it is that Ego’s exist. They are there because what we do is so often in the "magic" realm. This is a perception from society, that whether right or wrong, exists. It doesn’t matter that a Farmer battling 12 years of drought who manages to get through to the next harvest is just as miraculous as coding the engine for Unreal Tournament.

We are seen as nerds. "Supa" nerds if you will.

And for me, that’s okay. I’m kind of a pseudo-nerd anyway.

Who are we? What do we wish to accomplish? How much bragging can we do? How much competiton should there be between programmers?

It all begins and ends with our own self.

Instead of babbling some more, I’ll get straight to the point.

We all know someone who thinks they are pretty awesome at what they do. We all know someone who thinks they will always be more right than us in any particular situation. We know that we ourselves can be this person.

And truthfully, we know that most of that crap is just being insecure. Security of Self leads to a far better understanding of our work. We can get on with learning without being hampered by petty fights and jealousy.

Sure, it’s gonna happen. And sure, competition is an awesome tool. But most of the time I never see healthy competition, I see insecurity rearing it’s head, creating wierd social situations and complex mind-warfare. Why is this? Because of half a hundred reasons I expect, some of them from my own personal insecurity experiences.

But it’s not the why here that matters. It’s how we react.

Back to the main point. Having an ego is fine and dandy. Never being able to be told you’re wrong, or admitting you’re wrong, or turning around and changing what you’re done … that’s where the stick gets stuck. You become a far better programmer, designer, developer if you are willing to learn, to admit you need to learn, to seek out better ways of doing things.

For me, after the shock of seeing that i was, in fact, wrong :), i never really think of it so much as being told i was wrong, as that there is a better way to do it. And that’s what I want. I don’t care that what I did before was crap, i know it was. I look back on old code all the time and curl up in the foetal position.

To realise the vision of Dev Dawn, some of these concepts need to be laid out in plain sight. A place of Ideas is only going to break down if we can never learn new things, or know we can improve.

So there’s another of my rambling 2.3 cent articles. It’s left-field, coming at some things that we talk about over coffee.

The Art of (War) .. Planning

I continue to be reminded of the importance of the Plan.

When working in a Project, developing a System, or part thereof, the first and best way to begin is planning. Or if you have jumped in half-way … same thing. The Plan man.

What does this mean? It boils down to, I think, a few important details.

  1. Clarity of Thought

    Whatever means you take (notepad, whiteboard, project management software, massive cranial capacity), it’s vital to gain some measure of clarity when working on a Project. No matter how small or large.

    This means knowing where you are going. Not just the big picture, but smaller pictures, goals, deadlines etc. It also means you know where you have been. Review the past week. Know what you have gotten done, and what you have not. It’s important not to cheat yourself. It’s not going to help your own development as a developer (ha) if you aren’t honest. Know that you have missed a deadline, and rectify it.

    So I guess that’s a second point.

  2. Be Honest and Fix The Wrongs

    If you believe you’re the best programmer in the world, then i guess there’s nothing left to learn. But I know guys who believe they are great programmers (and they are in truth) but who also know that they will continue to learn until they pass out of this mortal coil. This is good. Better than good. It’s neccessary. We have to be willing to accept that sometimes we will miss our goal because we have stuffed up, or because of events out of our control.

    The next step is to fix it. Plan baby plan.

  3. Review and … Plan

    You can definately go overboard (never) with this. Balancing the planning and reviewing with the work itself is a skill. But if you’re still in the project, and you have a couple of hours without any pressure, or it’s the start/end of the week … review. Plan. See where you have gone, and where you want to be this time next week/month/year.

  4. Old & New Functionality

    This is where I was getting to with the other blather. I constantly find myself discovering old functionality that, basically, sucks. I created it with very little foresight. Almost no planning, just reacting to the client’s needs. There’s a billion words just in that topic … but anyway. What do you do? It’s the hard way. Either rip it out and create anew, or clean it up. Both a viable depending on the situation. One good aspect of cleaning it up, is that you get to make old code new … better and more sparkly :). But however it’s done … Plan. Sometimes you can just do it, code it straight up, because you have clarity of thought. "The problem is that the totalling is wrong" … "I went in and found a minus instead of a plus" …

    So what about brand new functionality. Again, the Plan man. Throwing in functionality is the bane of my life, because i’ve done it so much. And I continue to … but am hopefully getting better at planning a little beforehand. What will this affect (if you have an entity/module/thread diagram, you can hopefully find these things out a lot quicker), and what effects will be had? What’s the best way to get this functionality done … sometimes the fastest is best, sometimes the other.

I’ve babbled on … being the second article, I probably haven’t progressed with much of the above mentioned clarity … but it’s another step towards TOTAL WORLD DOMINATION … i mean … towards a great little library.