September 2015 – Tech leadership

All about imports

Have you ever used packagist? What about PyPi? If you are like most developers, well at least the sane ones, the answer is a resounding yes!

What however may not be as unified in response is how to actually arrange the imports.

Thankfully a best practise exists. Here we go.

Top level

First things first, here you should import any standard library import. That is packages that ship with your language of choice.

from math import sqrt
from os.path import abspath

Mid level

Right below you should import any third party libraries you use. This include any libraries that ship with your framework.

use App\Http\Controllers\Controller;

Lowest level

This is where you put in any code that you are reusing from within the app.

import payroll.Employee;

That is as a general heuristic import first items nearer to the core language.

How do you import in your own application? Talk to us in the comment section below.

Yes you should version your database

There is one major process that your team is likely ignoring that holds a large stake in your application, can you guess what it is?

Did I hear someone say Database migration woop woop top of the class!

More often than not, we properly version code but deploy the database as one big sql dump. Practically all teams I have interacted with during deployment present a .sql file with instructions that Mysqldump or a similar tool should be put to employ.

The biggest disadvantage to this method is that the database and the application don’t remain in sync for the various versions available. At first glance this may not seem like that much of an issue since most of the time we are only concerned about the final version of the db. However when you think about it you realize that if the version of db you have is only the latest, then earlier versions of the code are practically unusable since they work with the implicit assumption of how the schema of the database is structured.

Application <-> Database mismatch maybe your biggest problem but other problems quickly become apparent when you deploy and need to scale your app. Since the entire db is just one big dump, you can not easily automate the task of scaling it over the cloud.

Well now that we have talked of the evils of the dump, what can we do?

The easiest option is to store diffs of the database. Here I don’t mean in the sense that git does but rather storing ALTER scripts in an orderly incremental manner in a folder called migrations. Sample contents would be:

001_Users.sql
002_Products.sql

And when say we alter the users table then:

001_Users.sql
002_Products.sql
003_Altered_users.sql

etc

We then commit the files to our code repository of choice.

This ensures that at whatever point you checkout your code, you can also be able to generate the necessary schema.

Other considerations

For those who work with frameworks, your framework probably ships with a schema builder in one form or another. For those cases you may wish to version the schema files rather that the sql file.

For those of us who prefer the db to be framework agnostic, the following tools can be a great help to help you run your diffs

How do you manage database migrations within your own team? Tell us in the comment section below.

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