Software is not like traditional engineering disciplines. Unlike a bridge whose requirements are essentially set in stone, software requirements consistently change and evolve with the needs of the business. The requirements, of say civil engineering, are more firm and concrete than that of software engineering because the artifacts that are being constructed are usually large physical objects like a road or bridge. In the other hand, software is malleable and it often refactored easier than business constraints, that is why product managers often prefer to wedge a round peg (software) into a square hole (requirements) as business constraints evolve. But unlike a kid’s shape sorter or pegboard set, the peg and the hole are consistently changing and not always into the same shape.
It is hard to explain to family members that even though I “work with computers” as a software engineer I can’t always fix their computer problems. I tried to explain it to my grandma that I am more like a “race car driver than a mechanic when it comes to computers. I know how to use a computer but not how to fix the weird noise your computer makes.”. To which she responded, “oh that is fantastic, I can’t get this printer to work… It complains that I need a driver.”
From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of recent tweets and rants. If you want to follow the conversation follow me at techknow and/or juixe.
- Say no to consultant code. No to complacent code. No to sloppy and crappy code. No to cut and past code.
- Developing a machine learning algorithm so we don’t have to learn anymore.
- Hacking, art or science!?
- Great hacking weather… Well most weather is great hacking weather as long as your computer don’t overheat.
- What would an autonomous algorithm do?
- Sex, drugs, and hacking.
- You don’t go on Hacker News to show off your project, act arrogant that it’s a closed network, and not expect someone to hack a clone.
- Nothing worse than setting a test to run overnight only to have a Windows update restart your computer in the middle of the test/night.
- Refactor with conviction.
- Building on assumptions is like building on quicksand.
- When in doubt, step through it in a debugger.
- Every problem is an opportunity in the rough.
- Mo’ money, mo’ problems. Mo’ problems, mo’ opportunity.
- Ask the right questions is better than making the wrong assumptions.
- Everything is mental, even when it’s physical.
- Being successful means you are only a mistake away from not.
- Don’t use the fact you don’t know a fact as a reason for not knowing it.
- Just because a team member knows one thing does not excuse the rest of the team from learning for themselves and knowing it too.
- A team is composed of a group of individuals, but a group of individuals is not a team.
- Google used to be a search engine and return search results now it wants to be an answer engine and return you the answer.
- What do you call a Pinterest user? Pinner? Pinhead?
- Facebook IPO: it’s complicated.
- How hard is it to add filters to Flickr’s iPhone app?
- These @calottery lotto ticket should have a QR code so that I can quickly scan to see if I’m a winner.
- The Google of today is the sort of operation that Sergey and Larry originally set out to disrupt.
- Somewhere some evil genius is building a super computer out of a cluster of The New iPad.
- AT&T is in the phone business, so of course when you call customer support they will always have you call someone else who transfers you that gives you a different number that redials…
- P.S. GitHub sorry, I was bored. — Egor Homakov, the guy that hacked GitHub
- I have never seen someone try so hard for attention while looking so atrocious at the same time. -Anna Wintour on Nicki Minaj
- I would give my life for her but she also wants me to do the dishes. – Hellboy
- Are you killing time or is time killing you?
- Do The Simpsons pay royalties for basing their episodes on popular movies?
- Why do single people love cats?
- Why is it that sometimes when you don’t do a thing people notice, but when you do they don’t?
- Which would you prefer, an iPad with a keyboard or a net book?
- If you could only attain one thing which would you choose, money, happiness, or longevity?
- Fear is free but it will cost you opportunities.
- Ideas are cheap, but originality will cost you.
- Hot sauce makes everything better.
- The odds of you being a loser are better than you winning the lottery.
- There are people I follow on Twitter that I would never follow in real life, who I would rather push of a cliff in real life.
- Complainers are worse than haters.
- College is not for the uber successful.
- future obituary: died of chili cheese fries.
- “Really? Really?” Is the new “Oh My God”
- The term “gateway drug” doesn’t make sense, if you are already doing a drug, you are already past the gateway for drugs.
- Power drinks are the new gateway drugs.
- Power drinks are making me fat and jittery.
- All advice is relative, especially advice from a relative.
- Life is a journey not a destination, death in the other hand seems like the destination.
When working with legacy code, there is a big difference between a developer trying to add or fix a feature and getting it to work and another developer trying and giving up only to recommend a complete rewrite. From my experience, the one main reason why any person suggest a complete rewrite of an existing application or feature that works for a large install base is only because they don’t understand it. I would be suspicious of any engineer or developer if he or she recommends to rewrite any large portion of a existing appellation just because because they don’t understand it.
Rules to code by…
- No consultant code.
- No complacent code.
- No crappy and sloppy code.
- No cut and past code.
As a business, if any client has any sort of problem using your software then it’s your problem. Non technical users will have trouble using your software because of an array of issues, such as permissions, settings, configurations, other software, and external devices. No matter what, you have to make the effort to get them started using with your software or not. I’ve seen issues at different client sites because one software application required one version of Java and another required a newer version. Typically you can have multiple version of Java on a computer, but these two applications demanded that only over version exist and that it be the one they require. I’ve seen issues where end users print from an application and complain because they don’t see the document printed in their laser jet, it was printing in another printer in another floor and they didn’t know how to configure it correctly.
As a development lead, if any programmer has any sort of problem with your architecture then it’s your problem. If someone doesn’t understand an design and they have to work with it, they will make changes that can cost you in the long run. If you make a system overly complex, there will be a time that you will have to delegate that to someone else and they will not understand it as deeply as you and will make changes to fix the bug of the day, but cause another problem to be discovered later.
Whether an end user doesn’t know how to change the printer or a new developer doesn’t know how to implement your design, it’s your problem and it should be addressed with something other than blaming the confused.
Sometimes it’s because you took on the wrong client, or hired someone without the technical background, but it is still your problem. Often times, the problem is basic communication and availability of training material. Always, examine these situations and see how you can improve the process, training, and communication of your team.