yegor256 podcast

Latest Episodes:

M57: Tech startups fail mostly because of software development incompetence Mar 21, 2019

Show notes

Why do startups fail? Conflicts between investors and founders, marketing issues, lack of customer development, not enough money, etc. I believe that all those issues are secondary. The primary cause of problems is the inability to manage programmers right and make sure they deliver what they promise to deliver. Everything else happens as a consequence of the technical incompetence of the software team. The video is here: https://youtu.be/AwN4emJT0n4

M56: Don't expect your architect to be an expert in your tech stack, that's what developers are for Mar 20, 2019

Show notes

Very often our customers in Zerocracy expect software architects to be very knowledgeable in the tech stack they are going to use in their projects. Even though it doesn't hurt, but this is not what software architects are for. An architect is not going to be the knowledge provider in the project, instead, he or she has to know where to find the right experts, how to engage them, how to motivate them, and how to deal with the information flow they provide and programmers work with. Soft skill is what differ an architect from a regular programmer. The full video is here: https://youtu.be/_XPonwxsXGI

M55: The programming language you choose must match your project business objectives Mar 19, 2019

Show notes

Many customers, who pay for software development, think that some programming languages are fast, while others are slow and when they need a great/fast/awesome application, they need to use the language some other team has been using before and managed to create some other great application. This is the wrong approach. Instead, when you choose the language pay attention to how it matches your business objectives. Whether your project is going to be alive for a month or a few years, how big will be your team, how much money do you have to hire experts, how disciplined is your management style, etc. Almost any language can create a fast application, but not any language is suitable for disciplined management. The full video is here: https://youtu.be/Pz256gcyuHs

M54: Make sure you control your programmers and do it explicitly and openly Mar 18, 2019

Show notes

I've heard it very often that people don't like the word "control" being applied to a group of programmers. They find it abusive, offensive, and de-motivating. I absolutely disagree with this. Control is abusive only if it's implicit, hidden, and not obvious. However, if the rules of work are well defined, accepted by everybody and applied strictly, just like those laws we all know in civil life, control is not abusive at all. The video is here: https://youtu.be/ezE0hRH9BnQ

M53: What do I think about Agile? It's a recipe for disaster, if you are a project sponsor. Mar 15, 2019

Show notes

Agile, as a software development methodology, was invented by programmers and for programmers, to make things easier for them and to get a perfect excuse when things go south. In Agile the management is not in charge anymore, can't control things, can't really predict anything, and can't blame programmers for mistakes. If you are a programmer, Agile is your perfect shield against most of the problems in the office. If you are a project sponsor, it's your ticket to failure. The full video is here: https://youtu.be/OOAMNOso46g

M52: Three-branches release model: Master, Release Candidate, Live Mar 14, 2019

Show notes

In order to isolate your production from the "dirty" master branch, I'm suggesting to use a simple release/delivery model. First, you let everybody commit to the "master" branch, of course, after they pass all unit/integration tests and the entire merge pipeline. Then, you create a candidate branch, which you deploy to the staging environment and let your testers break it as much as they can. Then, when it becomes obvious that testers can't find anything critical there, you the "candidate" branch into the "live" branch and deploy to production, via the deployment pipeline. You may have a number of release candidates, staying in testing simultaneously. This model proved its validity in many projects I've been doing over the last years. If you tried it and there were problems, please let me know in the comments.

M51: Don't hide error stacktraces, make end-users part of your quality control instead! Mar 12, 2019

Show notes

Most big websites I work with don't show their error details when something goes wrong. Here is an example: my account with Amazon is in trouble and I see nothing except the "We are sorry" message from them. Instead, I believe, would be much better to show me much more technical information and make me part of the development process. That's what we do in our projects: making our technical defects as much visible for end-users as possible, in order to make them fixed faster. The video is here: https://youtu.be/t1locjBAXYY

M50: Testing is the process of confirming that the software has defects (JPoint talk rehearsing) Mar 11, 2019

Show notes

The biggest problem of modern software testing is that neither testers, nor programmers, or their managers understand the role of a software tester. A tester is not someone who confirms that the software works as intended. Instead, a tester is the one who confirms that the software has bugs and who knows how to discover them and document. I will be speaking in JPoint in a month, exactly with this topic. Here is a short rehearsal of my presentation for them. I'm interested in your comments, criticism and suggestions. The video is here: https://www.youtube.com/watch?v=D5RtdHicCXE

M49: Zold is an experimental non-Blockchain cryptocurrency, made by Zerocracy Mar 07, 2019

Show notes

There are many cryptocurrencies on the market, while 99.9% of them are based on the Blockchain architecture, with some modifications. About a year ago we decided to try to create our own solution, which would be a true alternative to Blockchain. It seems that we managed to achieve what we planned and now it's the right time for you to join us and convert your bitcoins to zolds. This is how you will help Zerocracy and will make yourself a profit. The video is here: https://www.youtube.com/watch?v=5A9uBwMow0M

M48: If you depend on your programmers, you are a bad architect! Mar 06, 2019

Show notes

If I would need to create software for a nuclear power station, who I would work with: freelancers or full-time employees? Of course, the first intent is to get a team of full-timers who we can "trust" and who will care about the business, will be committed to it and will feel personal responsibility. However, this is a very wrong idea. The business will eventually suffer because of lost control. In order to stay in charge of the quality the business should work with people who care mostly about themselves. Freelancers are exactly that type of people. If you manage to deal with them and keep them under control, your business will be strong and successful. The full video is here: https://www.youtube.com/watch?v=12SEpsOH7CE

Our TOPPODCAST Picks

Follow Us

Stay Connected

Related Podcasts

Links

Stay Connected