CTO? info to make you think

One day soon, (or maybe this just happened?) a young, slightly warm person, will show you an image not unlike the one you see here:

The person will smile quite a lot and wave their hands and point out boxes in an enthusiastic manner. At the end of the session, they will say that there are obviously a few small problems and that the new upgrades you asked for will need a few more weeks or months of work. Then you'll pick up your phone and call someone like me to come audit your codebase and see why there are problems.

The person like me will arrive and spend a week looking intently at the screen, searching the code base, looking at your code and you will ask for a quick fix whereupon the consultant will show you that rather than the lovely diagram above, your code actually looks similar to this:

This is the typical picture that is seen in software projects in which the words "Quick Win" or "Fast Response" are used as design criteria and where the manager of the project says that "Testing uses resources that might otherwise be used to generate code" or that "We must be agile" where agile means an ability to change things quickly, in other-words to claw yourself out of the large hole you just spent five years digging for yourself.

The only way to prevent this from happening to your code is to place as much value on software quality and understanding your code as you place upon the product itself. Code quality assurance costs you money in the short term but will save you your job in the long term.

Looking for a job?

http://www.bbc.co.uk/news/business-21938085

Hardware and software, an uneasy partnership

I guess that fundamentally I am a lazy hardware design engineer. I say lazy because I found many years ago that programming on top of someone else's hardware was much easier in some respects than having to design the hardware before you began the task of programming.

Many of my early works were embedded processor driven with no "operating system" to speak of, usually a Z80 or 8051 processor running code from the first available memory location and all under my control.

Modifying a hardware design is very hard and requires a different timescale of lead time than that of software yet unfortunately, the software will be what sells the job to the marketing people so its really important to get that combination right. A hardware design engineer will need to get all the aspects of the design pretty much correct before any sort of manufacture is done, a software engineer can play with, modify or change their design more or less at will within a certain number of constraints.

I have recently gone back to the very fundamental aspect of hardware design and I am creating a system that has no underlying operating system, is heavily dependent on hardware that performs tasks that might otherwise be seen to be software tasks and the hardware is built from scratch with the most important components being the equations that I am using to define the parameters of the hardware. This is a really difficult departure for another part of the team who will need to design the software for the job.

The trick to making the two work harmoniously is in designing a high-level protocol that will satisfy all of the requirements of communication early on in the process and then creating mock components that can be used to develop the software before the hardware is fully finished.

CTOs Read This!

Does your software engineering department suffer from MILDEW?

MILDEW is Manager Induced Long-term Degradation Error Ware and is an effect seen by numerous companies that don't take care about the hiring and promotion criteria for software project managers.

This is something seen often in larger companies with a pyramid style hierarchy that follows the old-style management procedures of perceived meritocracy. Often they include older, more established companies that have added an IT department to keep up with the times but who have placed that department into the hierarchy in a traditional manner. Here is a scenario that I have seen on many occasions in the companies I have worked for.

A manager, we'll call him Fred, came into the company as an employee ten or fifteen years ago. He was young, dynamic and full of ideas and has his name all over the code. As Fred was loyal and stayed with the company, he found that his tenure was rewarded by little promotions here and there until he eventually became head of his team, often overseeing his own code. As he progressed, his responsibility shifted to other projects and he seemed to excel as a manager and so had a position in the company where he was well known and trusted. Times changed and he worked more on budgets and team oversight, leaving the project management to people who he hired because he liked their style. He saw a steady and satisfying progression in the product and reported his satisfaction to the CTO who thought that it was good.

The sad reality is that Fred is out of touch, he has no clue how the software works now, if he was to look into it then it would be mostly unfamiliar to him and any technical decisions that he takes will be arbitrary at best and probably downright damaging.

The software will have been developed to show "Quick Win" values for project sponsors and a true analysis of the code-base will show fragility and architectural chaos.

Be careful who you promote. It might be better to hire in a manager that has up to date ideas than to promote within the ranks. Above all, make sure your top manager can talk the talk and walk the walk. Don't let your software architect just draw boxes and arrows on a whiteboard and think that's enough.