When I use the terms
Smart,
Lazy, and
Developer; I mean the following:
- Developer as in energetic and focused on building real-world code solutions
- Not a dreamer who never gets around to writing anything practical
- Smart as in able to think things through (i.e. not smart-ass)
- Lazy as in lazy-loading, that is taking time to write code (i.e. not couch potato)
Good development is
lazy development a.k.a. patient development; it happens when the developer spends the time necessary to think through all the pathways of the solution that he is developing
BEFORE writing the code. That is
lazy-writing of code, i.e. not writing code before the problem is understood. The more due diligence a developer does to make sure that he is writing the correct code will reduce the amount of code that needs to be written.
This
due diligence takes the form of:
- Really understanding the requirements and getting product management (business analysts) to be clear on what are the ACTUAL requirements
- They often are not given time to gather requirements
- They often don't have access to the right subject matter experts
- They sometimes have very poor abilities to synthesize consistent and complete requirements (see When BA means B∪ll$#!t Artist)
- Really making sure that you understand how you are interfacing to other developers on your team and other teams, this involves:
- collaboration in front of a white board
- producing diagrams (UML and Visio)
It takes time to do this due diligence to make sure that you have
consistent requirements and to make sure that you will have
consistent interfaces with your peers. However, developers are eager to start banging out code and spend hours at their desks banging out code.
In reality, less than 5% of that time is spent productively (see The Programmer Productivity Paradox). If you see developers spending 100% of their time staring at their screens with no human interaction then you are looking at some of the worst developers.
In reality, less than 5% of that time is spent productively (see The Programmer Productivity Paradox). If you see developers spending 100% of their time staring at their screens with no human interaction then you are looking at some of the worst developers.
It is a bad sign if developers are always coding
Productive developers are constantly checking their understanding of the requirements and making sure that they are staying in
sync with their team's code. Productive developers are in
regular contact with the product managers/business analysts and can often be seen
white boarding with their peers and architects.
There are definitely developers who use their years of experience to become more productive, in fact among the best developers:
- the ratio of initial coding time was about 20 to 1
- the ratio of debugging times over 25 to 1
- program execution speed about 10 to 1
- program size 5 to 1
Why is lazy writing of code so important?
Code is often written before the requirements are understood or gathered. In addition, quickly written code often fails to fit with everyone else's code; often, it is only during integration that this problem is discovered. Good developers are patient and realize that there is a cost to writing code quickly.
Developers become psychologically attached to their code
Bad developers are
reluctant to change poorly written code. Rather than rewrite suboptimal code, bad developers will simply
add more code to make up for deficiencies. Even worse, they tend to blame everyone else for having bad code. What you end up with is band-aid after band-aid that leads to a severely buggy and unstable system.
Don't get me wrong, good developers can find themselves in a situation where they have written
sub-optimal code. The difference is that a good developer will recognize a problematic section of code and:
- Refactor the code if the code is largely doing the right thing
- Rewrite the the code otherwise
When in doubt, be lazy and write code late!
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}