tag:blogger.com,1999:blog-86106892011-07-07T13:41:05.589-07:00Consulting and Coaching for Software Developers and ManagersJohn Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.comBlogger121100tag:blogger.com,1999:blog-8610689.post-1159988871554182972006-10-04T11:42:00.000-07:002006-10-04T14:22:40.723-07:00

Fellow programmers (or at least we think we are),I've always been bothered by the term "code construction" because we really don't spend that much time constructing code (especially those of us predisposed to getting a copy of some working code and making appropriate modifications :-) ).On top of that, I've been bothered by the notion of "software design". There has been a lot of talk for a

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com41tag:blogger.com,1999:blog-8610689.post-1132354475823143522005-11-18T14:52:00.000-08:002005-11-19T04:12:54.886-08:00

Managers: Here are some questions you may want to ask your developers:(a) How many test cases have you created in the course of your current project?(b) Can you run these test cases each time you make a significant change?(c) Do you have enough test cases to be pretty certain you will catch most things your next change will break?(d) Can you run all these test cases in less than 30 seconds? Can

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0tag:blogger.com,1999:blog-8610689.post-1115922080991001652005-05-12T09:43:00.000-07:002005-05-12T13:34:18.886-07:00

Last night at the Agile Bazaar in Cambridge down the street from M.I.T., I had a chance to listen to both devoted advocates of "agile methodologies", as well as software developers seeking some relief from the arduous path of their profession (admittedly, I also took the opportunity to subject said same people to many of my opinions). Some conclusions:(a) Agile methodologies are probably as

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0tag:blogger.com,1999:blog-8610689.post-1115395693625540412005-05-06T08:00:00.000-07:002005-05-06T09:37:49.036-07:00

One of the best indications of the quality of a programmer is their coding practice. Some of the best programmers I've known produce code almost mechanically in a consistent format which is very easy to read.Among their practices:Matching curly brackets in the same column. Of course an opening curly bracket on its own line generates more "white space" (more on this later). However, it is

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0tag:blogger.com,1999:blog-8610689.post-1099515945372765512004-11-03T13:46:00.000-08:002004-11-04T11:15:49.993-08:00

A huge amount of time, money and brainstrain is spent on trying to figure out existing code. It is my experience that far more is spent on this activity than on actually writing code or even fixing bugs. I'd like to share with you some experiences and a suggestion that will significantly reduce this expenditure. I'll start with the suggestion: Make certain software developers learn the history

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0tag:blogger.com,1999:blog-8610689.post-1097944858428168952004-10-16T09:09:00.000-07:002004-10-18T12:17:51.153-07:00

All this talk about good software development practices -- keeping an up-to-date project/task plan, sharing test exercises with QA, interviewing developers at the end of their projects -- is all well and good, but why don't these practices naturally take hold in most software development environments? The answer is simple -- good practices take hold only with proper training and coaching.

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com1tag:blogger.com,1999:blog-8610689.post-1097617495359568952004-10-12T14:35:00.000-07:002004-10-14T14:34:03.963-07:00

Today I'll go through a simple project planning exercise to show what I mean when I talk about generating a task list and test exercises. Although it generally isn't prudent to blindly apply any particular formula to software development, it seems pretty safe here -- I'm largely suggesting that developers think thoroughly before plunging ahead. The project I'll use for this illustration is my

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0tag:blogger.com,1999:blog-8610689.post-1097616301531586152004-10-12T09:53:00.000-07:002004-10-12T14:32:01.193-07:00

At the beginning of many software development cycles, good intentions abound about how everything will be done correctly and thoroughly this time around. These good intentions include lip service about "test plans" to be produced by QA. Much more often than not, test plans don't materialize. Why? Most QA people don't have a really clear sense of what to test until they have actual software in

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com1tag:blogger.com,1999:blog-8610689.post-1097169221864492162004-10-07T08:47:00.000-07:002004-10-14T08:51:31.573-07:00

Most development organizations are often like overloaded computers -- their CPU monitors pegged out at 100% most of the time, with an occasional brief drop. This is not exactly an environment where you can expect to make wholesale, immediate changes, so I'd like to talk about something even maxed-out organizations might be able to handle. I'm not saying this slight change won't have to be

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0tag:blogger.com,1999:blog-8610689.post-1097087662680214542004-10-06T10:39:00.000-07:002004-10-06T16:53:01.500-07:00

The woes of much of the software development business is rooted in failure to plan. I don't mean a rigid plan that everyone follows blindly off a cliff, but rather a plan which mirrors reality and is updated regularly. Let me start by relating a story two associates told me about a project which went south. I'm sure everyone involved in software development or management has their own version

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0tag:blogger.com,1999:blog-8610689.post-1097082985885000402004-10-06T08:59:00.000-07:002004-10-06T10:17:16.213-07:00

This entry is addressed to executives and investors of software companies. Why? Because you have the biggest stake in long-term health of your company. And given how common it is to find dyfunctional software development organizations, chances are that things at your company aren't exactly in the pink. Some red flags to alert you that things aren't necessarily poised for success in the long

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0tag:blogger.com,1999:blog-8610689.post-1097076663775185412004-10-06T07:58:00.000-07:002004-10-06T10:20:47.776-07:00

Someone once said something along the lines of, "If bridges were built like software, you'd have to be foolish to cross them regularly." Isn't it about time that the software development profession rose above its pedestrian level and became a real engineering discipline? Today there is a wealth of experience and a panoply of tested software development techniques that form the backbone of what

John Keklakhttp://www.blogger.com/profile/13837516459671223211noreply@blogger.com0