Category: Engineering

All about software, coding, geeking around. My engineer side of things.

Your Best Developer Tool : An English Dictionary

If you can’t put a name on it, you don’t know what it is. An English dictionary is your best programming friend.

If you can’t put a name on it, you don’t know what it is

Peer programming with a lead developer on an important iOS project, I discovered a plain English dictionary or a thesaurus is my best friend.

You need it to name your objects, variables, classes, services, folders, …

It’s the best way to see if you understand what you do. Concepts you will implement must have their own special vocabulary.

For example, we were looking at a name for a model object. The object had to be a pre-filling container to build a more complete report. It had to be displayed on an UI to be filled, and to be opened and transferred via an URL. So it was used both as front and backend representation.

Well, we searched a name for 2 hours.

The reason it was so difficult was that :

  • the concept was too close from another object, but different
  • the concept was vague
  • the concept had too many faces or too many responsibilities

We tried :

  • ReportExcerpt (hard to pronounce for French speakers)
  • ReportSummary
  • ReportIndex
  • ReportPrefiilingModel

We finally settled for : ReportSkeleton.

Thank you Mac OS Dictionary App 😀 (by the way it’s waaaay faster than the Internet, try it)

And it’s even more important if your are not a native english speaker. Don’t use a translator from your language to English. Search an English dictionary. You’ll win one level of vagueness and indirection of your idea.

dictionary

Software R&D : Stop Focusing On Technology

Some big companies have centralized development R&D. But sometimes, it’s simply not working.

Some big companies have centralized development R&D. But sometimes, it’s simply not working.

 

Start making developers better at choosing instead of choosing for them

 

Don’t misunderstand me (especialy you my dear colleagues who read this) : we need some kind of normalization in a company with a lot of different quality level developers. But if you focus on technological solutions you’ll risk to miss the point and make yourself useless. Especially on tight budget.

Do Less :

  1. Trying to produce One-Size-Fits-All-In-One-Inegrated-Frameworks
  2. Hiring intrusive consultants for a short term study
  3. Producing Out-of-the-real-world POCs (Proofs of Concepts)
  4. Listening to all exterior vendors that claim to have the best One-Tool-To-Rule-Them-All

Instead Start :

  1. Gathering common needs from different projects already in production or in the making
  2. Emulate innovation by offering a kind of Entreprise Github
  3. Best : go open source and participate to the real world solutions
  4. Organize as many education events as possible. It’s harder but cheaper than buying soon deprecated solutions.
  5. Create an internal StackOverflow to promote help between product departments that never speak together.
  6. Promote User Groups for both external (open source) tools and internals
  7. Look for the best practice, not the average one. For example promote and teach TDD and Continuous Integration.

What matters is not an all in one solution that will deprecate in 2 years, what matters is making the other average developers of your company better.

It’s about education, not technology. It’s not about methodologies, it’s about state of mind.

 

What Kind Of Lead Developer Are You ?

There are at least 2 kinds of Lead Developer. The Backup and The Coach. A leader is always someone making you progress in your craft. Either by teaching or by showing.

There are at least 2 kinds of Lead Developer. The Backup and The Coach. A leader is always someone making you progress in your craft. Either by teaching or by showing.

The Backup

He is working in the shadows. He is your safety net. Every commit, every unit test or method, he scrutinize it.

His goal is to soften the difference of levels between other developers. He is quiet and working on tasks you don’t see at first :

  • repairing or improving a unit test
  • reordering your files
  • answering your small questions
  • taking and applying merging decisions for your
  • making great utility classes and stacks to accelerate your work on the most visible part of your project

The difference with a simple developer is that he can explain what and why he is doing. Hence, you progress.

Each of his commit is to be looked at. Because they can and should change the way you code.

The Coach

He is spending more time with you than coding on his own. Peer programming with him (either as a pilot or a co-pilot) is a better than 2 months of school.

It can be frustrating for him, just like for the Backup leader; because he is more helping others to code than coding.

He is the guy you look after every time you start the architecture of a new user story. And you should. More visible he also have to be humble yet firm.

You Should Hire Both

They are complementary. There can be many leaders, not just one. And the time spent by the first must be used by the second to educate the team.

Both are the architects of the project, one by example the other by reputation.

I worked with a good combo on an iOS project. And it’s a joy to follow them, through the code, or in peer programming.

And you ? What kind of lead developers did you meet ?

 

Unit Tests Explained To Managers In 10 points. Test Culture Episode 12.

Here are 10 reasons why you, as a manager,  should care about unit tests. It’s a summary of this series of 12 articles on unit tests for managers. Continue reading “Unit Tests Explained To Managers In 10 points. Test Culture Episode 12.”

Good Unit Test CheckList

Writing unit test? but don’t know if you covered everything? Here is a simply good unit test checklist.

Here are a few items I try to respect every time I write unit tests. It’s a solid and good unit test checklist. At least good for most of my code 🙂

Edit: a more extended and detailed list I wrote for DZone.

  • My test class is testing one and only one class
  • My methods are testing one and only one method at a time
  • My variables and methods names are explicit
  • My test cases are easy to read by human
  • My tests are also testing expected exception with @Test(expected=MyException.class)
  • My tests don’t need access to database
  • My tests don’t need access to network resources
  • My tests respect the usual clean code standards (length of lines, cyclomatic complexity,…)
  • My tests control side effects, limit values (max, min) and null variables (even if it throws an exception)
  • My tests can be run any time on any place without needing configuration
  • My tests are concrete (ex. dates are hardwired, not computed every time, strings too…)
  • My tests use mock to simulate/stub complex class structure or methods

Maybe you’ve already done a great deal  by appointing a Test Supervisor that checks every aspect of the finished product. That’s terrific. Congratulations.

But there are still bugs ?  Your team is telling you that this little change you asked took the all system down ? How comes ?

For more details about unit tests, see my series:  Test Culture Episode 1. The 101 Unit Testing Guide For Busy Managers.

I’m pretty sure there are more point to this unit test checklist.  Any idea ?

Test Culture Episode 8. Moving Sh*t Around.

« If you don’t have unit tests, you are not refactoring, you are just moving shit around »

I’m so sorry. I could not find the source of this quote. But you get the meaning anyways. Or maybe not… Maybe you just think that unit tests are optional and refactoring is even more optional.

Continue reading “Test Culture Episode 8. Moving Sh*t Around.”