Tag: engineering

Coding by mistakes

All software design companies recognize how important it is to let its programmers make mistakes, as long as they have an established process. The idea of a branch-and-merge mechanism in version control software reflect this; the designer expects to experiment, make mistakes and fix everything before merging his code back into the code. While the programmers are not encouraged to make mistakes, making them in as safe a way as possible very often grants a team the freedom to make happy mistakes, where they learn a new trick, a simpler interface might be used or new approaches or functionality might be invented.

The team still has to work on a schedule, but the confidence to experiment new things is the first way to learn and improve. I believe it’s the best way of turning a team from good to great, especially if I use an agile approach.  I recently saw a funny video about ‘The Institute of Mixing Random Things Just In Case the Result is Good” – it had a better name, but you get the idea.  Random tests, mutations and errors are 99.999999% bad, but sometimes, very rarely, they are useful.  Awareness of it is important and encourages the open mind necessary to realize that an unexpected result might have a positive impact.

Have you ever tried out something or given someone a task and they come back with something that isn’t at all what you expected, but it makes the rest of the project better?  I could give you a few examples. An intern created a simple launcher (what I asked for) but stored more parameters than he needed to (a waste of resources at the time); it saved our bacon at a conference when the loaned machines needed a different configuration. A developer created an user-defined attribute system on top of the business objects (what I asked for), but the simple lightweight system meant that most of the previous storage code could be made irrelevant. Investigating performance problems of a tagging feature led to removing a very slow, convoluted and totally useless loop in unrelated database code.  Have you ever experienced this rare, but happy, event?

This morning I was wondering if the capacity to ‘revert’ things could be applied to anything else.  I know I often depend on ‘undo’ in my word processor to stop most of my logorrhea, or at least tide it back. I make a backup of drawings before I try to color them or edit them. It lets me screw up in confidence. But there are still plenty of places where I feel like I don’t know what I’m doing or if there’s a better way of doing it, and I can’t find out because I’m afraid to screw up.  Take this WordPress platform for instance. There are a ton of options and features I have never used and might never even try, just because reverting to a state I like might be impossible.

So where else could I use recoverability?  What software packages don’t have it but would be easier to learn if they did? Can I implement recoverability with simple, generalized backups in most cases? And do I actually learn to use my stuff better if there’s no chance of messing up?  Can I apply this to everything? Can I make a team better by giving them a safety net?  If I let a dev. team self-manage and edit their bug list instead of making it my exclusive domain, would they screw up or would they learn quickly and get more efficient at it than I would alone?

Any truly Agile process needs to adapt; being able to experiment (and having the freedom to screw up from time to time) is a basic need. I think it’s important to adapt your tools, processes and thinking to learning by mistakes and being able to revert at any time.

Knowing enough to get the job and staying afloat : learning by porting

Do you have all the skills you need to change jobs? While you’re busy working with one technology or managing a project, new technologies pop up.  Even if you make an effort to stay in touch, chances are you don’t get trained for the next job; only for your current one. So even if you do have a ton of experience, you might end up starting from the bottom again.

Job offers often repeat the same patterns of required knowledge and experience. In Québec, job offers usually require you to have 2 years of experience in a specific programming language or technology for a full-time job. A position for an experienced software developer requires at least 4 years, in multiple technologies, and expert positions very often require 10 years of experience in a specific technology, even if it has not been widely used for that long.

I believe that sometimes you can replace depth of knowledge with breadth. For example, if you want to apply for a C# job without work experience in it but you have worked with Java and other OO languages, an employer could still pay attention to your resume. Can you learn enough on your own qualify for a job requiring 2 or 4 years of experience? I’m leaving out ‘expert’ level; becoming an expert is a very different process than getting to a testable level of proficiency. To become an expert you need to  spend more time ‘hacking X’ than ‘using X’. It means spending time investigating a technology, not merely using it. So the actual number of years of ‘usage’ are not as relevant as being able to show you have investigated, reported and tried to improve on various parts of a technology. If you are an expert in something, you know that you are,  and don’t need my opinion.

I’ve spent some time hiring software developers;  I know that if some of the skills are missing or incomplete, I will still consider a candidate that can demonstrate a good spread of skills, because he or she has the capacity to learn.  How fast? What is the real difference between 2 years of experience and 4?  The important thing is to be able to show competence. Can you fill in the blanks in your knowledge quickly? Can you think your way through a problem or interview question?

The difference between a craftsman and a theoretician is practice. So you need to gain experience in new technologies quickly. What is the most efficient way? You can pay for certifications and seminars, but if you’re like me you’re an autodidact who doesn’t enjoy spending thousands of dollars and weekends when all you really want is to download some software package, Google for docs and learn at your own pace and time.  What to do? Pick a problem that uses one of the technologies you want to add to your resume, and come up with a project to resolve it. Design and implement it with the new technology. When that is done, solve the same problem with another technology.  Repeat till you’re confident you can show you won’t need 3 months to get to work in a potential employer’s environment.

For example I’ve designed a method for tracking requirements. The project isn’t the important thing; identifying what technologies I want to add to my resume are what matter.  I had never used C# or .Net in a project, so once I’m done designing the architecture and database, I code it in C#.  I can learn the basics of the language and the core libraries. Once I’m happy with the results, I can start over with J2EE.  The second run in the second language is much faster since I don’t have to redesign the software & database and the design bugs have been worked out. Then I can try again in Ruby, Python, and so Forth.  For a low time cost I can add learn new skills.  It may be a bit boring, but it’s hardly redundant and wasted time.

If this is obvious or common sense it should be easy to test. I’ve actually coded the above project in C#. I’ve learned a few things specific to .Net. Setting up and learning how to configure web.config, using code-behind and file layout correctly and understanding very obscure and unhelpful error messages took the most time; figuring out the libraries, running queries and using controls was very easy using Visual Studio. I plan to reprogram the same thing using J2EE and Eclipse, I won’t have to focus at all on the design, only on learning the differences in coding and libraries.  I will note how long it takes to do the second versions and the following ones.  Who knows, I might change my thinking of how quick learning a new technology and becoming proficient with it can be much, much faster than ‘common knowledge’. Let’s not forget that most studies on this date from pre-Internet days where programmers might expect to use the same programming languages for a very long time.

I’ll post the results as soon as I have anything interesting to report.  If you have any questions or suggestions please add your comments, I am eager to hear from you!

Too pretty to code

These days, if you are not a Cruise, Jolie,  Depp, Jobs, Raymond or any kind of Beautiful People, then leading a major software development project is not for you. Or if you succeed, you might have a charismatic associate, because lately it seems that you really need to add well-groomed to the long list of required talents of a project lead.

One of the most surprising aspect of Software Development, whether you’re trying to help your team make technical advances or help people use better software is how much charisma is necessary.  Nerds and computer-oriented people are still often depicted as clueless and lacking in social graces.  What else but leadership is going to motivate your team to code the next, greatest app or get angels to invest in something that can’t be seen or touched?

Let me prove it with the following completely fictional tale:

The startup is well-run. It is housed in a red brick building in the historical part of downtown, but clearly there’s no money wasted on trivialities; creaky wood floors, a receptionist surrounded by dead plants and sometimes, during winter storms, snow makes its way through gaps in the windows and drop into the back of your shirt.

The team is top-notch too; experts in their field, tons of degrees (even PhD!), an efficient management team; the only people dragging their feet are interns feasting for hours in the cafeteria.

And the project itself is perfect; the software is useful, there is a demand for it, and it has really picked up speed since you signed on. There are just enough technical challenges to make it both deliverable as planned yet interesting enough to keep the team focused. And wonders of wonders, the project is actually funded!

It’s a happy, sunny little coding shop. Until the launch. Until doomsday. Until Fate destroyed the Gods using the vilainies of bad diction, adult acne and fat.

The plan is to announce the software and wow investors into funding the marketing effort. As the software itself is spectacularly boring to look at (mostly because that’s all the graphics skills that could be mustered in the absence of real designers) there isn’t even going to be a real demo.

Picture the scene, a full team of geeks and nerds dressed in their Sunday best welcoming journalists to their seats.  Big shot investors sitting in the front row, beaming from the expected ROI. And then… No drum rolls, just an uncomfortable quiet as a bald, rotund man wallows up to the microphone.

“Heh. Greetings, huh,  everyone… Today We… hmm.. Our company and hm… We… and I, I mean… I guess…”, the speaker fumbles, hesitates, pines for the miraculous oratory abilities he dreamed of last night. (It’s the Kung Fu Panda Theory – It will be okay as long as you think you’re special!)  Less than five seconds into the speech and a pall has fallen on your future.  “Who is that idiot?” is heard from the front row.  “The CEO, the guy you wanted to fund.”

And there it is, thousands of man-hours, creativity and talent wasted because the only person who was not required to have actual software skills couldn’t be bothered to practice a speech.  And you wouldn’t or couldn’t replace him. Couldn’t afford to dress up your software in something sexy. We rarely have the option of choosing our boss, and startups don’t usually have the gumption to hire image experts.  Is it possible that now on top of being able to herd cats, hit impossible deadlines and debug code written in a language you just picked up two hours earlier, you also have to be too pretty to be a nerd for your startup to succeed?

It seems that companies have caught on to the power of star designers. Sexy nerds are still in.  But frankly if you’re in a technical management position, you practice just-in-time learning for most things, code at random hours of day and night and have a significant other so that at least one person knows you own a tie. You don’t have the time to hit the gym or check on sexy trends. And if you did, you’d be the CEO, not the code gnome.

Sexy: you’re damned if you do, damned if you don’t. The sad truth is that if you are a software nerd, chances are that you really aren’t that great at decoding people or making them hang to your every word.

If you can’t be sexy yourself (are there classes for nerds?), can you afford not to make your software sexy instead? If you can make it sexy, will management fund it? Can ANY software be made sexier?

What is sexy software anyway?

So many questions, so much knowledge missing from the Development curriculum! But if you really intend to design insanely great software, I believe somehow you have to figure out how to look insanely great yourself.

The Four-Sided Triangle

More than ten years ago my boss explained the Software Management Triangle to me.  As he taught project management to engineers, I expected it to be timeless and precious wisdom. He wandered into my nobicle (it only had one wall so not a cubicle) and revealed that our project was in trouble. But he had a cunning technique to get back on track.

“Time, Cost or Scope.”, he said in a decisive tone, “Pick one.”.  The project was his baby so I knew reducing the scope was out of the question. We also liked the loose deadline. Thus only the Cost was changed; it spiraled out of control and the project was shut down.  That was my introduction to the Triangle.

What my would-be mentor did not mention is that the sacrifice for cutting down on any of those three items was Quality, which we wanted to keep high. However there is another, hidden part of the Triangle that can affect all others. It is known by many names but I like to call it simply “Location! Location! Location!”.

I believe that even in this era of telecommuting and high-speed networks, being in the right place is still an important aspect of success.  There is still no better way to understand someone’s requirements than to meet them face to face. It is still difficult to get people interested in your projects or what you can do if they can’t see you.  And synergy and other partnerships just can’t get started without a good handshake or some other way to get a ‘gut feeling’ about the other party. Off-shoring and outsourcing are all about changing the location factor; this change can improve or reduce quality.

That’s why I want to announce that I made the jump – from a small city with lots of resources (especially top-level programmers and analysts) but no real funds and large enterprises to Montreal, where there’s so many openings that rifling through IT jobs search engines takes about 20 hours.

Now all I need is some time, money and scope to manage!