Ignore them at your own peril

A big problem exists in the tech industry. Specifically that it seems that software development is considered analogous to coding. This misconception is very dangerous and may very well be the reason your next project fails!

Lets start by looking at what the definition of coding is:

    Coding is the mechanical translation of preexisting design into a computer language.

By that definition we can already tell there is more to software development that just coding, so what is this more. Steve McConnell to the rescue! In his epic book Code Complete aptly nicknamed The Bible by software designers, Steve lists other processes that relate to the building of software, below is the listing;

  • Problem definition
  • Requirements development
  • Construction planning
  • Software architecture
  • Detailed design
  • Coding and debugging
  • Unit testing
  • Integration testing
  • Corrective maintenance

As you may have noted, coding is way down the list!

Going through all this steps might seem like a lot of bureaucracy and that doesn’t play quite well with us techies who most got into technology to avoid it. Still you should consider the steps for all non trivial projects.

The reasons are many but below are samples:

Scheduling

Scheduling is a pain to even the most experienced practitioners in the field. In a previous blog post Simple Software Estimation we talk about how to estimate the time it will take to write software. However the client/market cares about how long the entire process of software development takes. By having a more holistic view of the processes. You will be able to give better estimates.

Usability

Users of your application care only if the product meets their needs, by giving proper credence to earlier stages of the development process, you are more likely to build a product that the market actually wants not what you think they want.

Resource management

Administrators in the project can get a better view of the entire project and see what resources they will need when they will need them and level which they will need them. This helps avoid last minute rushes hunting for talent.

Code quality

The single most effective way to boost the quality of your code is to work on the design. The benefits of front up design are many, I will likely cover it in another post but suffice it to say planning architecture of your code helps you avoid writing Spaghetti code

Emphasize all tasks

If you don’t make a conscious effort to consider the other phases, you are likely to simply ignore it and jump straight to coding! Properly considering all aspects ensure that they all get their spot on the table.

What is the software development process in your own organization? Talk to us in the comment section below

Facebooktwittergoogle_plusredditpinterestlinkedinmail

So you want to become a master developer?

Done with your first two projects? Great! What we are going to discuss today is the one fundamental skill that is guaranteed to take your skills to the next level.

I am sure you already guessed it, that is practise.

Before proceeding its important to clarify what practise is NOT working on a project for a client is not practise, that is work. In fact if thats what you do, please open up a new tab and quickly fire an apology to all the clients whose money you have been wasting!

Practise is an entirely different beast, Geoff Colvin in his book Talent is overrated talks of the following characteristics of practise or deliberate practise as he calls it.

Its designed specifically to improve performance.

Keyword here is designed, this requires knowledge about how performance is developed and improved.

This means that you likely need a teacher to help you in your practise sessions. However it is essential that with time you become good enough to design your own practise.

If you are looking for a nice school to join try Moringa (Disclaimer: I train at this school)

It can be repeated a lot

Unfortunately humans are not Write Once. To get better at any task you need to repeat it a lot. This means that the tasks carried out in the practise routine must be inherently repeatable safely.

It is highly demanding

If you find yourself in flow, you are probably not practising. In fact it is physically impossible to carry out practise for more than 5 hours a day and for more that 1 hour a time. This can act as a useful guideline to know if what you are doing really is practise.

It is not fun

Unfortunately practise is no going to be a pleasurable activity. I will let Emeka Mbadiwe explain the concept

Practising like a chess master

It’s not always possible to get a teacher, but thats no excuse to not practise, we can borrow a leaf from the world of chess.

Professional chess players practise by studying positions of pieces for different games played in the past.

The positions are organized by various themes including

  • Openings
  • Attacks
  • End games
  • Defenses

They then compare the move that they would make in this position vs the move that the master made.

We can modify the process to use in our own profession.

Steps

  1. Look into requirements specification, an implemented RFC or popular algorithm. Check this book by Dr. Sedgewick Algorithms for inspiration
  2. Write out your own implementation of the algorithm
  3. Look for an implementation of the algorithm, if you are using Sedgewick’s book, you will find code samples.
  4. Evaluate the proposed solution against your own
  5. Note the differences between what you did and what the authors did
  6. Rinse and repeat

You can use this method to analyze other aspects of software development as well including:

  • Design patterns
  • Specification drafting
  • Scheduling
  • Deployment
  • etc

Point is to identify gaps in your existing skillset and subject them to the rigors of practise.

How have you designed your own practise? Talk to us in the comment section.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Simple Software Estimation

Estimating how long it will take you to write software is a crucial yet often ignored skill. No matter the size of the project, it’s good to get into the habit of estimating your projects.

You don’t really need a complex system to achieve this. Here is a sample of a simple spreadsheet to get things of the ground.

Simple Estimation

Simple Estimation

This method was borrowed from Joel Spolsky book http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/

Some important points to note concerning software estimation:

KISS

As usual we are back to our beloved principle, your estimation platform should be as simple as you can make it. That is tasks should be as fine grained as reasonably possible. You should be thinking in tasks lasting 30 mins to at most 2 hours. In short a coding session.

It’s possible that you have longer coding sessions but I still believe you should keep it to this chunks.

Let the developer do it

There is evidence that letting people set their own schedules leads to boosts in productivity. Below is the findings of research carried out by Lawrence and Jeffrey from the University of New Wales. http://www.amazon.com/Programming-Productivity-Mcgraw-Hill-Engineering-Technology/dp/0070328110

Programmer Productivity

Programmer Productivity

Of course there is a caveat to this general rule as can be seen above, system analysts generally give better estimates. This is because they have more estimating experience. Still unless you have the budget for a system analyst, stick to the rule.

This is a living file

The column Curr Estimate and Elapsed time should be continuously updated. It is my suggestion that you take 10 mins after your coding session to update this values.

When you start of, your estimates are likely to be spectacularly wrong, however, if you discipline yourself to always update the estimates you will slowly but surely get better at this task as you learn from your mistakes and hone your estimating skills.

Version your estimates

It is critical that your estimates are part of the source. Whenever you commit your code, ensure there is a csv with your estimates within your project.

This gives you an opportune time to actually update your estimates before a commit as well as help you track the time used over long periods.

Tracking time

On this item you can either decide to use a time tracking software such as Toggl or use general estimates based on time spent.

This really is a matter of personal choice though you should strongly consider time tracking software if you or your agency bill by the hour.

Other considerations

It is important that you include other items that affect the schedule but are not programming tasks, this would include:

  • vacation and family time
  • debugging time
  • buffer time
  • deployment time

I hope I have been able to show the importance of scheduling and a simple way of achieving it. If you agree or have an even better method, share with us on the comments below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail