Category Archives: Coding

Why popular programming languages may be bad for your programming career

A careful reading of Making it Big in Software will surface two curious observations. First,  I studied the popularity of different programming languages and platforms.  Not surprisingly  I found the Java is the most popular programming language in the world.  Nice, but not exactly world news.  It stands to reason that if Java is the most widely used, it’s where the job are,  right?  So if you wan to be marketable, you may draw the conclusion that you need to stay fresh on your Java skills.   Then I interviewed Mark Russinovich, Microsoft Technical Fellow, and Windows architect. I asked Mark for his thoughts on what people should keep in mind in order to have successful careers in software. Here’s part of the advice he offered:

“Try to differentiate yourself. For example, when Java exploded in the mid-1990s, everybody became a Java programmer, and the market became flooded with cookie-cutter Java programmers. It’s really hard for people to stand out as something that isn’t easily replaceable in that world. My whole career I have tried to stay away from that. Operating system internals, while not considered particularly sexy or part of the mainstream, have allowed me to stand out because of the relatively few people who go into that and the perception “Wow, that’s really hard.” Stay away from the mainstream and the crowds, and find something that is gonna be stable—not just flash-in-the-pan technology.”

Mark isn’t saying you shouldn’t be a good Java programmer, and neither am I.   Knowing Java is definitely good! But if that’s you primary skill and claim to fame it’s going to be hard to distinguish yourself.   Be distinguishable. Most of the time programming skills are to software as hammer, lathe and drill are to a carpenter. Tools of the trade, yes, bu not where the deeper talent lies. Being an expert in tools doesn’t make you a great carpenter, because the essence is knowing how to make the table, the cabinet, or the armoire.  In most cases software is the same way, and programming simply provides the tool to apply your real talent. What really distinguished you is your deeper knowledge of the domain you’re applying those skills to, such as databases, social networking, communications, multimedia design, financial analytics, scientific domains and so on. In Mark’s case it’s operating systems. Ya… I’m sure Mark knows how to code, but that’s not what made him a Microsoft Technical Fellow.

TAKE THE POLL! What matters more to your career – tech skills or soft skills?

 

Cast your vote  HERE!

 

—-

Why software project management is like painting a Rebrandt (or, knowing when done is done)

Rembrandt Harmenszoon van Rijn (July 15, 1606 – October 4, 1669) was a Dutch painter.   When you see his paintings you can’t help but be amazed by their detail and lifelike nature.  The problem with paintings, especially the ones that are based on classical realism, is that there’s always one more stroke of the brush you can add. The painter is never finished. So too with software. There’s always one more test case to try, one more error scenario to trap, and one more use case to cover.   That’s why, left to their own devices, software projects never end.

Does everyone have a clear understanding, and does everyone have the same understanding of “done”? Ask around in your team  – I absolutely guarantee that in most organizations people do not!  

RED FLAG WARNING: Software developers love to say things are “basically done”.  The problem with “basically done” is that it usually translates to 90% ‘functionally’ done, but the last 10% of the work could take more than 50% of the time. As they say, the devil is in the details and the details are always in the final 10%.

Because there’s no such things as exhaustive development (and in particular, testing with full branch and code path coverage) one of the most important steps a software project manager can take in driving a high-efficiency team is to make sure that everyone in the organization understands the definition of “done” for the pieces they are working on. When is the code done? When is testing done?  It’s not as easy as it sounds, but it’s an effort well worthwhile. 

More on secrets of software project management in Chapter 15 of Making it Big in Software: Get the job. Work the org. Become great.

ITWorld’s interview with author Sam Lightstone.

Columnist and author James E. Gaskin interviews Sam Lightstone for ITWorld.

“Career advice: Making your mark in software programming”

http://bit.ly/aDYva6

Avoiding software project overruns: watch the ratio!

In Making it Big in Software I discuss 11 reason why software projects run late (see Chapter 13).  In this post I’ll mention just one – my favorite. It’ my favorite because it’s ubiquitous, subtle and is fundamentally about programmer psychology. 
  
Software developers are notoriously poor judges on how long things will take.  Fred Brooks  (author of the Mythical Man Month) found that the following rule of thumb allocates time for software development with reasonable accuracy: 1/3 specification and design, 1/6 programming, 1/4 function and integration testing, and 1/4 system test. Over the past 30 years those ratios have held true (of course, they vary from project to project). Over the past ~15 years, the more mature teams in our industry have finally come to terms with the reality that testing is half the effort of a software development cycle, and that’s probably the biggest reason project success rates have been improving. Testing, in this context is the entire test cycle, which includes both the effort to plan  and execute the tests, as well as the effort to fix the problems it surfaces. We still have major problems on the front end, and these are the areas that most significantly damage individual careers.  Why is that happening? 
 

  

For a wide range of emotional reasons, software developers refuse to believe that coding represents only 1/6 of the software development cycle. They refuse to believe this because software programming is fun, and it’s what  they want to spend their time on. It’s just too depressing to believe that the very thing they jump out of bed excited to do, the very thing they planned to spend their professional careers on, represents so little of what they will actually be doing. 
    
Programmers like to believe that programming is relatively hard (which it is) and that other tasks, such as testing and writing, are comparatively easy (highly questionable). So when you ask developers how long a piece of work will take, they are thinking predominantly about the coding effort. However, what the project manager was usually asking for was an estimate for the total effort, including specification, design, and testing – or at least all the work up until testing. One tactic to avoid these issues is to only let programmers estimate what they are good at estimating: the coding effort. The ratios are well-known and hold true across a wide range of projects. If you can get a reasonable estimate on the coding effort from the engineering team, you can extrapolate easily to determine the time for design, specification and testing.  The coding estimates are usually the most accurate sizing a programmer will produce:    
 
   Design and spec = 2 x coding estimate   
   Function and integration test = 1.5 x coding estimate 
   System test = 1.5 x coding estimate     
  
 These guidelines are simplistic, and, of course, well-known exceptions exist. Features that add performance value (speed) but otherwise leave externals unchanged require performance quality assurance but functionally may require little testing beyond regression testing (to ensure that what used to work still works). Dependencies between features under development always add delays as teams spend more time collaborating to understand a broader set of requirements. Although I don’t recommend applying these guidelines naïvely to all projects, they make a good starting point for most. Then you can revise the estimates for the outliers as a (sometimes major) refinement.      

Whether you let the programmer estimate some,most or all of the required work, its worthwhile to sanity check the estimates they provide to make sure they’re in the ballpark of reasonable. If testing is less than 25% or design and specification are less than 15% it should raise a large red flag for you.    

Chapter 13 of Making it Big in Software: Get the job. Work the org. Become great. has the full story, along with the other 10 causes for software development overruns and how to handle them.  

Recommended for every serious programmer

 

There are a lot of qualities that separate a serious software engineer from a rank and file developer. Here are a few technical skills and experiences I recommend:

1. Learn at least 4 different programming languages and at least 4 different data formats (such as JPEG, XML, delimited text, and MPEG).
2. Develop software that is suitable for at least a thousand people to use concurrently.
3. Develop software that can scale to more than 1TB of data.
4. Work on a project with more than ten programmers.
5. Work on extending code that someone who is no longer available to ask questions of wrote more than five years ago.
6. Fix at least 40 defects in code you did not author.
7. Write code that supports international languages, including UNICODE input, and more than one language of generated user output (error messages, GUI text, and so on).
8. Study the performance characteristics of the following:

  • Data fetched from memory with and without a CPU cache miss
  • Reads of consecutive blocks from disk versus random I/O seeks
  • Large block I/O versus small-sized I/O
  • Three popular languages (such as Java, C/C++, and PHP)

These are the skills that people need to develop software “at scale”. By “scale” I mean scale in data, scale in concurrency, and scale in development organization.  Development at scale separates the serious software professional from the rank and file journeymen programmers.

Making it Big in Software: Get the Job. Work the Org. Become Great.

Making it Big in Software is now available for pre-order on Amazon.com and Barnes & Noble.  Three years in the writing, I’m absolutely delighted with how the book has turned out.

Discover how to:  •Get your first job in software development •Master the nontechnical skills crucial to your success •Understand the “sweet science” of software R&D •“Work the org” to move up rapidly •Successfully manage your time, projects, and life •Avoid “killer” mistakes that could destroy your career •Move up to “medium-shot,” “big-shot,” and finally, “visionary” • Undestand the “Law of Promotability Inversion” • Even launch your own winning software company.

Featuring exclusive interviews with leading personalities from industry and academia including Microsoft’s CTO, Salesforce.com’s CEO, the inventor of Java, the inventor of email, the coinventor of the Internet, an IBM Fellow, and many more.