Navigate / search

For more photos and on photography please go to my photography site at Pascal Parent Photos

  • brainstorming

    Software Architecture

    Thoughts on enterprise, solution and software architecture More

  • user


    Thoughts on people and system management practices More

  • graphic-design

    Tricks and tips

    Helpful tips and tricks to make your life easier More

  • comment

    Having coffee with...

    The podcast with interesting people. More

The Democratic Development Philosophy – Part 1

I have been in software development for over 20 years, throughout these years I have seen a great many techniques applied to curb the software development project failures. As we went from a waterfall approach that has become too lengthy in our ever-demanding instant gratification world to the latest agile methodologies, the big picture and the output qualities are vanishing and the individual fading.

Software development today seems to be about wowing the client, whom ever that might be, into a too often false sense of comfort about the project’s advances. The sooner there is something to show the better for the development team because the client will be happier. The management of the people in these software team are taking a back seat, it becomes all about that elusive happy client. But can you have a happy client without a satisfied team on the project? Probably, at what cost though?

But can you get both the happy creative software developer and the happy client?

I believe that it is not only possible but imperative to achieve and that brings me to an agile methodology that I have, and hopefully, you have, been using. I call it the “Democratic Development Philosophy” or DDP for short.

First it is important not confuse Agile which is a methodology and Democratic [Software] Development which is a management philosophy, it is vital to distinguish between the two, however both can and must co-exist to lead the team in a repeatable successful project cycle. Though I have seen Agile referred to as “Democratic Software Development”, see V.Rengarajan who refers to the SDLC and agility of the team, and only touches on the management philosophy, the paper found here.

The principles behind DDP are not only applicable to software development but also to any type of creative development team, I have only used it in software development. I need to add that I am no expert in this and only want to share my experiences of what has worked for me in the past.

There are some requirements to achieving DDP, the team needs to get along and have minimal internal politics, the individuals in the team also need to know and accept that individual ego will not be tolerated. These are important aspects to achieve up front as using DDP also requires every member irrelevant of age, experience or scholar achievements to have the same rights.

In many ways, DDP starts by being a round table exercise where every member has the same voice, the difficulty when starting with DDP is in the leadership. Most managers, architects or team leads have an inherent dictatorship within them and sometimes it is required but it must be avoided for DDP to succeed as this will only send the members of the team in a defensive state, the last thing you will want.

In a DDP team, the leader is the voice and the moderator of the team, the leader allows the team to get creative with solutions, nothing gets dismissed or laughed at. The answer to the current dilemma lies within the team, not within an individual. Because this is so, every member needs to speak their mind and give their opinion without judgment from others. It gets tricky, particularly in environments where very different types of characters exist in the team, it is up to the leader to ensure that no one gets oppressed. However, this is only the beginning, as the team’s trust grows in Agile Democratic [Software] Development, it becomes both a philosophy and a methodology where the team naturally creates what I call a brain trust.

Initially, the DDP is used in stand-ups and meetings, as the team coalesces into a single unit of trust, it becomes a way of life. Each member starts to bring more into the solution culminating into a better more stable and more desirable product.

Most of what follows becomes natural to the team, all the leader has to do is maintain the trust as the team gets better and faster.


The cost of bad developer hardware

I often get asked what hardware I would recommend for software developers, each time without fail I have been asked about my sanity.
Admittedly, at least to non-IT people, I probably often sound insane, just ask my boss.
The truth though is not as insane, most developers will need a machine that meets the following requirements:

  1. Run an office package
  2. Run a database at acceptable speeds
  3. Run the development IDEs and compilers at acceptable speeds
  4. Run a virtualization environment at acceptable speeds

Add an Instant Messenger, often Skype, a browser or three and a music app.
You may ask why the virtualization environment and the music app, let me address the virtualization environment.
The latest trends in software development use virtualization to ensure that the configurations and setup of the development environments match the production environment and everything in between. An example of this is the rise of docker in the development space. It also allows the developers to use virtual machines for other simulations, I often run an entire data center with load balancing and firewalls to ascertain risks and how viable the design is. I will admit that this is an extreme use case but running a web server, application and a database server is a regular occurrence. To be able to do any of this a computer with as many cores as possible, lots of memory and lots of drive space is required.
What about the music app? I will refer you to another article I recently wrote entitled Interruptions in the workspace.
Before I do a few calculations and give my recommendations, let me add one piece of hardware to the mix, web developers require 2 screens! Simply because they do not have to switch applications, one screen for the development IDE and one for the application. It saves time as the developer does not have to find their space on the screen where the code is after each switch.

Some calculations

In my calculations, I am estimating the time of execution and adding the frustration factor resulting in productivity losses.
Though this is not scientific by any means, this is observed behavior.

Condition Incidents
per day
Time lost
per Incident
Time lost
per year
Cost of
time lost
Cost of the
extra hardware
Compiling  32  30 sec  72 h  R 18 000  R15 000  R 3 000
Task switching  128  5 sec  48 h  R 12 000  R 10 000  R 5 000
Boot time  2  5 min  45 h  R 11 250  –  R 16 250
Disruptions  8  5 min  180 h  R 45 000  R 4 500  R 56 750

The baseline was calculated with the following values:

  • Developer average cost at R250 an hour at 8 hours a day on 22,5 days average a month (R 45 000 / pm)
  • Cheap Laptop price R 15 000
  • Developer laptop R 30 000
  • 2x 27′ Screens R 10 000
  • High end over the hear headset R 4 500

The theoretical savings are over a month salary for a single developer, even if you negate the disruptions remember that a slow computer comes with frustrations and that affect productivity, the savings are over the price of the cheap laptop.
The disruptions would also need some education to be reduced that is not factored here.
I think this clearly demonstrates the value of better hardware for developers.

The hardware recommendation

As of today, the specifications here below will cost less than the R 30 000 stated earlier.

  • Minimum 4 physical core processor, i7 with hyper-threading at highest possible speeds and maximum cache
  • Minimum 16 GB RAM
  • Minimum 250 GB SSD drive

A laptop is preferable, so your developers can work flex-time

My recommendation? Do not try to save on hardware, it will cost you more than you think.
These costs may not be tangible is the strict sense of the word, which makes true calculations difficult, but they become evident over time and number of employees.
Lastly, you get what you pay for, I found that laptop gets knocked around a lot, better hardware may just save on maintenance or repairs and thus downtime and IT support costs.


Interruptions in the workspace

Interruptions at work are inevitable and often exacerbated by the modern open plan office where sound and visibility have no barriers creating permanent distractions around us.

In South Africa, you can add a cultural angle to that, in that South Africans are not generally discreet and have no problems having a conversation across the office. This is often very disruptive and sometimes intolerable but respecting other cultures is a cornerstone of the South Africa.

There are some good articles around on the subject, in particular relating to programmers but this can be applied to the workplace in general, I particularly enjoyed ninlabs research’s and Atlassian’s take.

A question or two

Before I continue, have you ever wanted to pack up and go home to work felling you might get more done?
Have you ever done so?
Have you noticed an increase in your personal productivity?
Have you noticed it take you less time time to achieve the same amount of tasks?

This is probably because you were less disrupted, chances are you  can achieve and 8 hour office day in 5 hours at home and feel good about it, yet the same tasks will leave you exhausted at the office.

The problem

Let us define disruptions that cost us valuable productive time:

  • Walking up to someone and starting to talk.
  • Regularly walk up or call someone, that person will lose a lot (in fact up to 100%) of productive time.
  • Task switching, this can completely through people off.
  • Over-communication, whether by meetings, mail, IM or other,  if people are too busy communicating they are not busy enough being productive.
  • Office noise, this can bring a different type of interruption, the stress / concentration type. This includes, phone ringing, people talking across the room, etc.…

As a manager

there are some steps that can be taken, an office etiquette agreed to by all office employee is a good start, here are some suggestions that have worked for my environment:

  • When walking up to a person that is busy, let them acknowledge your presence and you wait until they complete their current thought.
  • Keep office noise to a minimum, in fact in creative spaces such as development team spaces ask people to step out to take calls or have isolation booth for that use.
  • Ask your employees to put their devices such as phones, tablets, laptops, etc. on silent .
  • If someone has headphones on do not disrupt them unless strictly necessary.
  • Have a 10 minutes status meeting first in the morning, often called a “stand up” from the scrum methodology.
  • Avoid meetings as much as possible, I find that about 50% of the meetings I attend are for presence only. These could easily be filled with productive time.
  • Avoid emails where possible.
  • Settle on an office wide instant messaging software and use it when required only.

As an employee

everything above still holds value but let me add the following:

  • When people abuse your time, let them understand they are doing so, most people will understand.
  • When people walk up to your desk acknowledge them or, if the task at hand is going to take a while, ask them if it is urgent or if it can wait.
  • If it is allowed in the office, get a good quality over the ear headset it will allow you to use voice over ip services like skype and isolate you from the rest of the office while listing to music.
  • If you can, keep your mail and IM applications closed, or set them to do not disturb, and look at them first thing in the morning, at 10:00, lunch time, 15:00 and before you leave.
  • Avoid meeting at your desk, rather formalise it.
  • Try to avoid meetings where you know you will not get or bring value.
  • Some times, if your employer allows it, work from home.

Though the subject of working from home and virtual offices is not part of this discussion as it open an entire other can of worms, it is worth mentioning that it is a possible solution not to be discounted.

In conclusion

These recommendations have helped me to create better more productive and happier teams without impairing communication.
It also has resolved a lot of interpersonal team member issues relating to irritations leading to a calmer environment.


The true cost of hiring a junior team to start a software project

In the past decade, I have been hired by many companies where my responsibilities has been to fix and/or improve a software package built by an internal development team.
Software that was build by junior developers lead by business people.

Let me be clear I am not putting blame on anyone, I know a great many business people that are highly competent in their field and I highly respect them but in all honesty business people do not understand software development management and it’s subtleties.

The scenario

A new project is though of, it look like a promising endeavor, in fact it has the potential to either save the company millions of Rand/Dollar or make a good profit. Before the project can become a reality though a “quick” proof-of-concept or prototype needs to be created.

Problem case

The company specializes in freight and has no development skills, due to the sensitive nature of the project the company wants to keep it in-house, outsourcing is not an option. Budget is restrained because this is supposed to be a proof of concept.

Initial solution

The company hires a few junior developers fresh out of university to save money, it is only a POC after all.

The result

The business is one or two years down the line and the software package has proven it’s worth but has become impossible to maintain, the junior developers have left for greener pastures because the pressure put on them was enormous and often unrealistic or the junior developers are completely burned out and unable to fix anything. The business owners are furious because the project is 6 months late and the software is not stable. Does this sound like gloom and doom? Is the software project at an end?
The potential losses at a staggering R 3 500 000 ($ 233 000)
A very hard pill to swallow for any company.

The reality

At this time, most companies call on either a senior developer or software architect to resolve the problem.
After a few months of hard work and permanent over time, the senior developer or architect breaks the news to business, the software needs to be rewritten from the ground up and business either panics or tells the senior that they do not know what they are talking about, more often than not business goes into in denial which exacerbate the issue exponentially.

By the time that 18 months have elapsed the problem is often so deep and complex that the most seasoned developer or architect I know battles to resolve the issues without re-architecting and re-writing from scratch whilst the rest of the team is stabilizing the current system to achieve business continuity. By the end of the first year, the losses are evident and climbing fast we are at a project total cost exiting 7 million rand and undoable damage to reputation.

The cause

Junior developers are often easy swayed and forced into situations they cannot handle, even if this is unwillingly carried out by the manager. They also do not have the experience to understand that best practices, methodologies, architecture, documentation and planning will work in their favor in the long term. Juniors tend to jump in the work head first unconcerned about the consequences and that is perfectly fine when there is an experienced voice of reason, which is not the case in our scenario.

The result

Although the intent from business is a good one hiring many juniors thinking that they will be more productive and cheaper than a senior, this is hardly the case.
In our scenario, which is more common then we would like to admit, we are now 18 months later, R 5 000 000 spent, endless reputation damage, 6 months late, with staff issues and a product that barely works that is extremely difficult to maintain or extend.

Business often goes the live with it way it is and decide to do the re-write years later when the company’s development maturity has reached a point where the value is evident. Often, the company has lost millions in the process.

The solution

Hiring junior developers in a situation like this is not a bad idea, it is important to understand the value of having a strong senior developer or better yet a software architect in the mix. The senior/architect will bring the maturity into the team immediately, they will bring the best practices, methodologies, architecture principals, standards, documentation principals, planning and general wisdom that startup projects sorely need. They may seem like an expense but if you look at it closely they become assets and savings.
A 1 year medium project based on the same requirements as the scenario will cost you 2,5 / 3 million rand in the first year, an additional 3,5 million in the second year with no damage to reputation. Total cost 6,5 million rand, we still have the original team and the product is going from strength to strength.

Obviously, this is not always true, there are exceptions but I would wager that it would be true in most cases.
My last 10 years have been spent in this scenario and I was told more than once, “You should have started 2 years ago” and I agree, never underestimate the value of a senior or architect.


Seed Project Methodology

I thought that I should explain the methodology I will use to create the Seed Project.

Each use case will go through a full SDLC (Software Development Cycle) that will follow the following pattern:

  1. Problem analysis
    What is it that we are trying to solve.
  2. System Analysis
    What do we need to solve the problem
  3. Solution Design
    How are we going to solve the problem
  4. Development
    Let’s build it
  5. Test
    Lets’ make sure it works according to the requirements and design
  6. Deploy
    Upload to GitHub so you can download the sample

Unfortunately, a lot of these are iterative, I will handle that by returning to the original post and updating it.
I will ensure that I note the last change date and modification detail so you can follow.